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Executive  Summary 


This  research  is  an  examination  of  the  mechanical  design  and  optimization  of  rapid-cycle 
UAV  launchers  to  support  the  swarming  UAV  mission.  UAV  launching  systems  currently 
available  lack  many  of  the  capabilities  required  to  execute  the  swarming  mission.  Specif¬ 
ically,  they  lack  the  ability  to  rapidly  reset  in  order  to  launch  a  high  number  of  UAVs  in 
a  short  period  of  time.  Contained  within  is  the  design  methodology  and  testing  results  of 
one  of  the  first  existing  prototypes  of  a  launching  system  specifically  developed  for  rapidly 
launching  a  large  number  of  UAVs  to  support  the  swarming  UAV  mission. 

The  research  goal  is  to  design  and  build  a  working  UAV  launcher  prototype  that  meets  all 
cost,  schedule,  and  performance  requirements  for  the  Advanced  Robotic  Systems  Engi¬ 
neering  Laboratory  (ARSENL)  team.  From  beginning  to  end,  systems  engineering  (SE) 
practices  are  utilized  as  the  framework.  The  core  benefit  afforded  through  the  use  of  SE 
is  that  it  provides  the  necessary  tools  and  techniques  to  make  informed  decisions  through¬ 
out  the  process.  Multiple  SE  models  exist,  but  for  this  research,  the  desire  is  to  adhere  to 
the  DOD  guidelines  as  prescribed  in  the  Defense  Acquisition  Guidebook  (DAG),  Chapter 
4  [1].  The  guide  lends  itself  well  to  developmental  systems  like  the  one  in  this  study,  and  it 
also  adheres  to  the  accepted  terminology  prevalent  in  existing  DOD  acquisition  programs. 
An  overview  of  this  process  is  shown  in  Figure  1 . 

The  methodical  approach  to  system  decomposition  afforded  by  this  method  allows  the  en¬ 
gineer  to  fully  define  a  set  of  requirements  that  satisfy  the  operational  needs  of  the  stake¬ 
holders.  This  process  is  essential  to  product  development  because  it  defines  precisely  what 
the  prototype  must  “do”  to  provide  value  to  the  stakeholders.  In  complex  systems,  it  is  easy 
to  inadvertently  overlook  requirements  that,  if  omitted,  would  render  the  solution  useless. 
The  decomposition  process  is  used  to  holistically  evaluate  a  total  system  solution  in  order 
to  minimize  the  likelihood  of  this  occurring.  An  overview  of  the  top-level  requirements 
found  during  this  process  is  listed  below: 

R1  The  system  shall  be  capable  of  launching  50  aircraft  within  15  minutes. 

R2  The  system  shall  be  configured  such  that  a  maximum  number  of  two  technicians  are 
able  to  setup  the  launcher  in  15  minutes  or  fewer. 


Systems  Engineering 
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>  Delivered 
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°o 
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Solution 
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Definition 
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Analysis 
Architecture 
Design 


•  Decision  Analysis 
>  Technical  Planning 
■  Technical  Assessment 


>>* 
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Transition 
Validation 
Verification 
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Implementation 


Technical  Management  Processes 


•  Requirements  Management 

•  Risk  Management 

•  Configuration  Management 


•  Technical  Data  Management 
■  Interface  Management 


Enables  a  balanced  approach  for  delivering  capability  to  the  warfighter 


Figure  1:  DOD  SE  Process  Overview,  from  [1] 


R3  The  system  shall  demonstrate  a  failure-to-launch  rate  of  less  than  or  equal  to  one  per¬ 
cent. 

R4  The  system  shall  be  capable  of  reorienting  90  degrees  in  less  than  or  equal  to  15  sec¬ 
onds. 

R5  The  system  shall  provide  a  means  of  alerting  the  user  to  system  status  and  potentially 
unsafe  operations. 

R6  The  system  shall  not  require  an  alteration  of  the  UAV  in  such  a  way  as  to  make  it 
unusable  with  the  legacy  launcher  system. 

R7  The  system  shall  utilize  no  more  than  live  custom  components. 

R8  The  system  shall  be  shorter  than  16  feet  to  accommodate  transportation  in  ARSENL’s 
trailer. 

R9  The  prototype  developmental  costs  shall  not  exceed  $10,000. 

Once  an  understanding  of  the  system  requirements  is  established,  a  market  analysis  deter¬ 
mines  if  an  existing  system  is  capable  of  meeting  said  requirements.  Also,  this  process  aids 


xx 


in  the  identification  of  industry  design  standards  that  could  be  applied  to  the  developmental 
phase  of  research.  Results  indicated  that  the  market  had  not  yet  responded  to  the  swarm¬ 
ing  use-case,  and  a  unique  solution  was  warranted;  therefore,  the  process  transitioned  to 
concept  development. 

Concept  generation  and  design  selection  was  accomplished  through  the  evaluation  of  the 
proposed  system  against  stated  requirements  and  build  feasibility.  The  limited  manufac¬ 
turing  and  construction  capabilities  of  the  two-man  development  team  had  to  be  accounted 
for  when  selecting  a  concept.  Based  on  these  considerations,  a  belt-driven,  electrically- 
powered  solution  was  selected.  The  concept  shown  in  Figure  2  is  based  on  the  principle  of 
baseball  pitching  machines  that  utilize  compression  to  accelerate  and  eject  the  baseball. 


Following  concept  development,  design  goals  were  established  and  evaluated  using  DOD 
TRL  definitions.  Also,  a  risk  management  plan  was  generated  to  help  determine  the  cor¬ 
rect  order  for  technological  progression.  High-risk,  critical  systems  were  developed  first, 
followed  by  the  integration  of  less  essential  sub-systems.  The  progressive  introduction 
of  technology  was  accomplished  through  iterative  prototyping.  This  development  method 
allows  for  rapid  design  changes  to  both  address  current  issues,  and  mitigate  future  risk 
concerns.  The  proof-of-concept  (POC)  developed  during  this  phase  of  research  is  a  rolling 
chain  launcher  assembly  that  utilizes  a  3-D  printed  interface  to  connect  to  the  chain  during 
launch.  Attachment  of  the  UAV  is  accomplished  through  the  use  of  industrial,  double¬ 
mushroom  Velcro.  The  launch  technician  needs  only  to  position  the  aircraft,  and  apply 
light  downward  pressure  to  engage  the  Velcro.  At  the  completion  of  a  launch  stroke,  the 
drive  sprocket  redirects  the  chain  around  its  circumference,  thereby  breaking  the  Velcro 
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bond  with  the  UAV.  For  power,  a  four-cell,  48-volt  battery  array  provides  250  amps  of 
current  to  a  permanent  magnet,  DC  10.75  HP  motor.  An  overview  of  the  POC  is  shown  in 
Figure  3. 


Figure  3:  POC  Overview  with  UAV 

Throughout  the  prototyping  process,  the  suitability  of  the  system  was  continuously  as¬ 
sessed.  This  was  accomplished  using  a  series  of  developmental  tests  and  evaluations 
(DT&E).  The  purpose  of  this  type  of  testing  is  to  determine  the  current  TRL  of  the  pro¬ 
totype,  and  update  the  status  of  perceived  risks  as  they  evolve.  Also,  the  tests  are  used 
to  verify  that  the  design  solution  is  meeting  system  requirements.  Once  the  concept  was 
validated,  significant  investments  were  made  into  developing  a  metalized  prototype  with 
automated  systems  and  advanced  sensing  capabilities.  The  prototype  is  named  after  the 
high-current  draw  required  for  launch  and  is  shown  in  Figure  4. 
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Figure  4:  AMPPS  System  Prior  to  Launch 


At  the  completion  of  prototype  construction,  the  final  stages  of  DT&E  were  conducted  at 
the  ARSENL  testing  facility.  The  AMPPS  solution  either  met,  or  is  predicted  to  meet,  all 
requirements  established  at  the  beginning  of  the  design  process. 


Table  1:  AMPPS  Prototype  Specifications 


AMPPS  Prototype 

Weight 

245  Pounds 

Length 

12  Feet 

Width 

32  Inches 

Launch  Velocity 

38MPH 

Reset  Time 

4  Seconds 

An  abbreviated  table  of  specifications  for  the  Automated  Multi-Plane  Propulsion  System 
(AMPPS)  prototype  is  shown  in  Table  1.  The  launcher  is  at  a  TRL  of  six,  and  technological 
risks  are  minimal.  Also,  the  solution  was  delivered  on  time  and  under  budget.  The  success 
of  the  system  is  directly  attributed  to  the  team’s  adherence  to  using  established  SE  practices 
from  research  conception  to  completion. 
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CHAPTER  1: 
Introduction 


This  thesis  is  an  examination  of  the  mechanical  design  and  optimization  of  rapid-cycle 
unmanned  aerial  vehicle  (UAV)  launchers.  UAV  launching  systems  currently  available 
lack  many  of  the  capabilities  required  to  execute  the  swarming  mission.  Contained  within 
is  the  design  methodology  and  testing  results  of  one  of  the  first  existing  prototypes  of  a 
launching  system  specifically  developed  for  the  swarming  mission.  Swarm-capable  UAV 
systems  represent  the  apex  of  airborne  autonomy,  and  are  likely  to  play  a  significant  role 
in  the  future  of  unmanned  air  power  [1],  [2].  Supporting  systems  that  enable  this  emergent 
technology  are  likely  to  hold  valuable  strategic  and  monetary  stakes  in  the  UAV  market 
for  both  defense  and  private  industries.  The  Teal  Group,  an  aerospace  and  defense  market 
analysis  firm,  recently  projected  annual  UAV  spending  to  nearly  double  from  $6.4  billion 
to  $11.5  billion  over  the  next  10  years  [3].  The  summation  of  this  estimate  accumulates  to 
$91  billion  by  2024  [3].  If  the  Teal  Group  is  correct,  there  is  an  immediate  need  for  support 
equipment  that  enables  the  future  of  UAV  mission  capability  growth. 

To  fully  illustrate  the  basis  for  this  design,  it  is  important  first  to  examine  a  brief  history 
of  UAV  development.  The  historical  study  of  UAV  capability  growth  provides  valuable 
insight  into  the  benefits  afforded  through  swarming  UAV  missions. 


1.1  Early  UAV  History 

Many  consider  UAVs  to  be  a  relatively  new  development  in  aircraft  technology;  however, 
the  general  concept  originated  several  hundred  years  ago,  shortly  after  the  1783  invention  of 
the  balloon  [4].  In  1818,  Charles  Rogier  suggested,  in  a  treatise,  that  enemy  harbors  be  at¬ 
tacked  by  bombardment  from  unmanned,  rocket-carrying  balloons  [4].  This  was  presented 
as  an  alternative  to  the  time-period  convention  of  land  or  sea-born  attacks.  Though  not 
immediately  implemented,  an  adaptation  of  his  idea  occurred  several  years  later,  in  1849, 
when  Austria  launched  unmanned,  bomb-carrying  balloons  against  Venice  [5].  Though  not 
very  effective,  this  attack  marked  the  first  historical  occurrence  of  aerial  bombing  [6].  Also, 
if  one  relaxes  the  current  Department  of  Defense  (DOD)  definition  of  a  UAV  that  requires 
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the  aircraft  to  be  controlled,  it  can  be  reasonably  deduced  that  this  was  also  the  first  use 
of  UAVs  for  aerial  bombing  [7].  Despite  Austria’s  rudimentary  execution  and  marginal 
impact,  the  same  concept  of  aerial  bombing  was  the  premise  that  fueled  the  United  States’ 
entry  into  UAV  development. 

The  first  UAV  built  in  the  U.S.  would  not  be  possible  until  1912  when  the  Sperry  Gyro¬ 
scope  Company  developed  an  automatic  control  system  for  the  Curtiss  Flying  Boat  [8]. 
This  system,  dubbed  the  “Sperry  Aeroplane  Stabilizer,”  was  created  to  help  mitigate  the 
inherent  instability  found  in  early  aircraft  designs  [8].  Although  the  initial  intention  was  to 
reduce  pilot  workload  during  flight,  its  future  implementations  would  prove  far  more  ver¬ 
satile.  As  was  the  case  with  many  emergent  technologies  during  that  time,  the  impending 
U.S.  entry  into  World  War  I  would  rapidly  propel  the  interest  in  developing  military  ap¬ 
plications  for  commercial  products.  Sperry’s  autopilot  was  no  exception.  Using  the  Curtis 
N-9  seaplane  as  a  platform,  the  Army  began  conceptual  application  testing  for  the  world’s 
first  autonomously  controlled  flying  bomb  [2].  Although  the  program  was  riddled  with 
early-phase  failures  and  eventually  canceled  in  1918,  the  Army  had  not  lost  hope  for  the 
flying  bomb  concept  [2].  The  contract  was  transferred  to  Charles  Kettering,  who  created 
the  “Kettering  Bug”  and  successfully  completed  an  autonomous  flight  of  40  miles  while 
carrying  180  pounds  of  explosives  [9].  This  became  the  first  U.S.  example  of  a  recognized 
UAV  system  [10]. 

American  development  of  the  UAV  and  supporting  technologies  continued  as  military  ap¬ 
plications  expanded.  Sullivan  notes  that  UAV  development  during  this  period  was  more 
evolutionary  than  revolutionary,  and  was  largely  driven  by  the  advancements  in  parallel 
technologies  as  opposed  to  directed  UAV  research  [10].  For  example,  much  of  the  sta¬ 
bility  and  control  logic  incorporated  into  UAVs  was  the  result  of  air-to-air  missile  devel¬ 
opments  such  as  the  AIM-9  [10].  As  the  supporting  technology  advanced,  UAVs  evolved 
from  marginally  operable  flying  bombs  into  highly  capable  reconnaissance  platforms  by  the 
1960s.  Cook  considers  this  period  the  transition  point  into  the  modern  era  of  the  UAV  [2]. 


1.2  Modern  Military  UAV  Development 

The  Vietnam  War  would  prove  to  be  a  hazardous  period  for  American  military  pilots  and 
aircrew.  From  1964  to  1972,  more  than  5,000  American  airmen  perished  in  downed  aircraft 
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[2] .  Additionally,  the  surviving  aircrews  who  were  captured  accounted  for  90%  of  the  total 
number  of  American  prisoners  of  war  (POW)s  during  the  Vietnam  War  [2].  Given  the  high 
level  of  risk  to  aircrew,  the  decade-long  engagement  became  a  catalyst  for  modern  military 
UAV  development.  Unknown  to  the  general  public  at  the  time,  UAVs  documented  3,435 
sorties  during  Vietnam,  with  some  vehicles  boasting  a  97.3%  completion  rate  for  low- 
altitude,  real-time  photography  missions  [9].  In  addition  to  reconnaissance  missions,  these 
UAVs  were  performing  battle  damage  assessment  (BDA),  electronic  intelligence  (ELINT) 
missions,  and  distributing  propaganda  leaflets  [2].  It  is  important  to  note  these  missions 
were  being  accomplished  with  no  risk  to  human  life  and  at  a  significantly  reduced  cost 
compared  to  manned  aircraft  [2].  While  this  represented  a  very  successful  demonstration 
of  military  application  for  UAV  use,  the  missions  were  considered  to  be  of  low  strategic 
risk  and  non-combative.  Because  of  this,  the  United  States  would  remain  skeptical  of  the 
platform’s  potential  to  perform  in  high-stake  scenarios  or  combative  missions  [2].  It  was 
not  until  Israel  demonstrated  the  combative  capability  of  UAVs  that  U.S.  military  officials 
became  interested  in  further  development. 

Beginning  in  1978,  border  conflicts  were  occurring  between  Israel  and  Southern  Lebanon 
[2].  The  Lebanese  were  using  SA-6  surface-to-air  missiles  against  Israeli  forces  who,  in 
response,  began  using  UAVs  to  overwhelm  the  Lebanese  targeting  systems,  exhaust  their 
missile  supplies,  and  act  as  expendable  targets  to  protect  the  Israeli  manned  fighters  [2] 
[9].  The  UAV  defense  tactics  worked  and,  despite  the  several  technical  and  capability 
deficiencies  with  the  platform  -  such  as  an  inability  to  fly  at  night  -  the  overall  outcome 
proved  to  the  United  States  that  UAVs  could  “perform  valuable,  real-time  combat  service 
in  an  operational  environment”  [9]. 

After  Israel’s  successful  military  demonstration,  UAV  technology  began  rapidly  develop¬ 
ing  through  the  late  1980s  and  into  the  turn  of  the  century.  As  interest  grew,  the  supporting 
technology  advanced  and,  as  a  result,  UAV  mission  capabilities  expanded.  The  first  no¬ 
table,  large  scale,  U.S.  UAV  acquisition  program  revolved  around  the  Israeli-built  Pioneer. 
This  platform  flew  over  300  reconnaissance  missions  in  the  Persian  Gulf  and  received  high 
praise  for  its  effectiveness  as  a  reconnaissance/surveillance/target  acquisition  (RSTA)  and 
over-the-horizon  targeting  (OTH-T)  platform  [2],  [11].  After  the  Pioneer,  UAV  platforms 
began  rapidly  emerging.  With  each  new  development,  capabilities  expanded. 
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Figure  1.1:  RQ-2B  Pioneer  (U.S.  Navy), 
from  [13] 


Figure  1.2:  20  RQ-4B  (Northrop  Grum 
man),  from  [12] 


As  new  UAV  capabilities  were  introduced,  the  necessity  for  advanced  autonomy  became 
apparent.  Longer  loiter  times,  increased  range,  and  increasingly  complex  missions  made 
rising  logistical  requirements  a  concern.  Consider,  for  example,  Northrup  Grumman’s 
RQ-4  Global  Hawk.  The  UAV  first  flew  in  1997  and,  as  its  name  implied,  the  sys¬ 
tem  had  a  global  range  of  12,000  nautical  miles  coupled  with  a  35-hour  airborne  en¬ 
durance  [12].  Other  UAVs  followed  similar  trends  in  prolonged  mission  duration,  such 
as  General  Atomic’s  40-hour  endurance  Predator  UAV  [2].  Compared  to  the  Pioneer’s 
range  and  endurance  of  100  miles  and  five  hours,  the  added  mission  capabilities  afforded 
to  these  systems  was  substantial  [13].  Even  the  visual  progression  shown  in  Figure  1.1  and 
Figure  1 .2,  from  what  is  essentially  a  sophisticated  remote  control  airplane  to  the  Global 
Hawk,  is  telling  of  the  advancements  made. 

Within  ten  years  from  the  start  of  significant  UAV  development  in  the  United  States,  UAVs 
were  not  only  performing  the  manned  aircraft  missions  in  parallel  as  a  force  multiplier,  but 
they  were  also  exceeding  manned  platform  capabilities  in  key  performance  areas  [14].  It 
was  at  this  time  that  autonomous  capabilities  entered  a  period  of  exponential  growth  that 
was  driven  out  of  operational  necessity.  Figure  1.3  shows  the  DOD’s  graphical  representa¬ 
tion  of  this  growth  as  published  in  their  2005  UAV  Roadmap  report  [1]. 

The  period  from  1985  (Pioneer)  to  1996  (Predator)  saw  significant  advancements  in  the 
area  of  telemetry  reporting  between  the  operator  and  the  UAV.  If  a  fault  or  error  occurred 
onboard  the  aircraft,  this  information  was  relayed  back  to  the  operator,  who  could  then 


4 


Autonomous  Control  Levels 


Figure  1.3:  Trend  in  UAV  Autonomy,  from  [1],  [2] 


make  decisions  about  the  appropriate  course  of  action.  The  functionality  was  similar  to 
an  annunciator  panel  in  modem  aircraft  that  alerts  aircrew  to  a  system  fault  or  malfunc¬ 
tion.  While  useful  for  increasing  situational  awareness  of  the  system’s  status,  levels  one 
and  two  of  autonomous  control  were  not  aimed  at  removing  the  human  component.  They 
were,  however,  necessary  developments  toward  this  end  state.  As  demands  for  UAV  pres¬ 
ence  in  military  operations  rose,  the  operator  demands  presented  a  significant  sustainment 
challenge:  One  of  the  largest  costs  in  ongoing  UAV  support  is  manpower  [7].  The  then- 
current  system  required  a  large  crew  to  operate  one  UAV.  To  satisfy  a  reduction  in  both 
manpower  and  fiscal  resources,  the  intermediate  goal  was  to  achieve  a  level  of  autonomy 
that  would  allow  a  single  operator  to  control  multiple  UAVs  [7],  [15].  The  desired  end- 
state  was  for  UAVs  to  be  self-piloting.  The  full  tactical  realization  of  this  capability  allows 
for  UAV  formations  referred  to  as  fully  autonomous  swarms.  Swarming  behavior  repre¬ 
sents  the  apex  of  autonomous  technology  and  is  shown  as  Autonomous  Control  Level  10 
in  Figure  1.3.  This  research  is  focused  on  the  development  of  supporting  technologies 
surrounding  swarm  UAV  capabilities;  therefore,  it  is  beneficial  to  review  the  fundamentals. 
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1.3  Swarm  Overview 


Swarming  is,  at  its  most  basic  definition,  a  decentralized  form  of  cooperative  action.  It 
is  an  exploitation  of  information  sharing  between  lesser  capable  units  that  become  more 
powerful  through  collaboration.  Many  authors  point  to  nature  as  the  true  origin  of  swarm¬ 
ing  behavior  [16],  [17].  John  Arquilla  notes  that  swarm  tactics  can  be  seen  in  the  insect 
colonies  of  ants  and  bees,  for  example  [16].  These  insects,  without  direction  from  a  cen¬ 
tralized  source,  are  capable  of  rapidly  launching  a  coordinated  attack  through  the  use  of 
swarms.  An  attack  from  a  single  bee  or  ant  is  a  mere  annoyance,  but  an  attack  from  a 
swarm  of  either  insect  can  be  deadly.  Although  a  high  number  of  agents  are  an  advantage 
to  swarm  attacks,  quantity  is  not  what  defines  a  swarm.  Rather,  it  is  characterized  by  the 
distinctive  behavior  that  swarms  demonstrate.  The  means  through  which  coordination  is 
achieved  is  what  makes  swarming  unique  from  other  cooperative  group  actions. 

Returning  to  the  example  of  ants  and  bees,  scientists  have  yet  to  identify  any  sort  of  DNA 
code  that  dictates  an  order  to  the  insect’s  swarming  behavior  [17].  This  suggests  their  ob¬ 
served  behavior  is  emergent  and  purely  reactive  based  on  localized  sensing.  Clough  argues 
that  swarming  behavior  is  implicit;  “it  just  is”  [17].  In  swarms,  there  is  never  a  desired  re¬ 
sult  or  explicitly-defined  outcome;  what  occurs  is  never  deliberate.  This  underscores  both 
advantages  and  disadvantages  with  swarming  behavior. 

From  a  biological  viewpoint,  one  advantage  is  that  swarming  species  are  highly  resilient. 
This  characteristic  also  applies  to  UAV  swarms.  Without  centralized  command,  it  is  dif¬ 
ficult  for  a  swarm  to  be  exploited  via  a  “checkmate”  type  scenario.  This  characteristic, 
properly  leveraged,  presents  a  notable  advantage  to  the  swarm.  That  stated,  there  is  a  limit 
to  how  many  units  may  be  lost,  and  that  limit,  or  critical  mass,  is  dependent  on  the  opera¬ 
tional  goal  or  mission.  For  example,  one  possible  use  for  swarms  is  a  defensive,  anti-missile 
“cloud”  being  utilized  like  intelligent  chaff.  This  swarm  would  continue  to  be  effective  so 
long  as  the  collective  density  is  high  enough  to  be  targeted  by  incoming  missiles.  If  the  at¬ 
tack  were  sufficiently  large  enough  to  the  extent  that  a  high  percentage  of  sacrificial  UAVs 
were  lost,  the  cloud  may  cease  to  be  efficacious.  However,  this  is  gradual  performance 
degradation.  There  would  not  be  an  instant  capability  curtailment  due  to  single  unit  attri¬ 
tion.  This  is  because  each  unit  in  the  swarm  is  homogeneous  and  would  not  individually 
possess  any  sort  of  critical  intelligence  driving  the  outcome.  This  is  important  because  the 
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species  exhibiting  swarm  behavior  in  nature  are,  in  general,  of  low  intelligence.  Species 
of  higher  intellect  are  capable  of  planning  collaborative  efforts  to  achieve  proactive  goals. 
This  advantage  in  perceptual  capability  usually  results  in  teaming  behavior  [17].  Teams, 
unlike  swarms,  are  capable  of  planning  the  desired  outcome.  However,  teaming  units  re¬ 
quire  higher  intelligence  than  their  swarming  counterparts. 

Implementing  a  group  of  autonomous  UAVs  with  teaming  tactics  would  require  each  unit 
to  have  considerable  computing  power.  The  resulting  UAVs  would  be  arguably  superior 
to  a  swarm  in  some  aspects,  but  the  expense  would  be  high,  and  unit  loss  would  there¬ 
fore  be  costly.  A  swarm  can  accomplish  some  of  the  same  missions  as  a  team,  but  for 
a  considerable  cost  savings.  The  reduced  intelligence  requirement  for  individual  units  in 
swarms  translates  into  lower  demands  on  computing  power.  Intuitively,  this  translates  into 
smaller,  lower-cost  solutions  for  swarming  UAVs.  With  budget  concerns  at  the  forefront 
of  conversation  in  today’s  politics,  any  reduction  in  military  spending  is  well  received.  For 
reference,  the  2013  Unmanned  Systems  Integrated  Roadmap  brought  attention  to  the  fact 
that  “the  2013  Presidential  Budget  (PB13)  [has]  reduced  the  overall  DOD  budget  by  $259 
billion  over  the  next  Future  Years  Defense  Plan  (FYDP),  with  a  total  reduction  of  $487 
billion  over  the  next  10  years”  [7].  It  goes  on  to  state  that  the  goal  going  forward  is  to 
develop  UAV  “capabilities  to  achieve  improved  efficiency,  effectiveness,  and  survivability 
and  to  reduce  the  burden  on  manpower  at  lower  costs  while  still  meeting  future  operational 
requirements.”  Essentially,  the  desired  end-state  is  to  accomplish  more  with  less.  A  swarm¬ 
ing  tactical  approach  is  well-tailored  to  achieving  this  goal  as  it  does  not  require  the  use 
of  costly  UAVs.  To  realize  this  capability,  supporting  technologies  will  need  to  be  devel¬ 
oped  alongside  the  basic  hardware  and  software  requirements  for  the  UAVs.  Of  particular 
interest  to  this  study  is  the  need  for  swarm-specific  solutions  to  launching  these  aircraft. 


1.4  Launching  Considerations  for  UAV  Swarms 

As  previously  discussed,  swarming  is  a  group  concept  that  requires  significant  numbers 
to  function.  This  presents  several  unique  challenges  to  launching  the  UAVs.  For  one,  the 
time  lapse  between  the  first  and  last  unit  launched  becomes  critical.  During  this  period,  the 
swarm  is  operating  at  reduced  capability.  Also,  the  endurance  of  each  unit  comes  into  play. 
From  the  moment  the  first  UAV  is  initialized,  it  is  consuming  energy.  Considering  there  will 
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likely  be  a  holding  period  while  remaining  units  are  launched,  this  translates  to  lost  range 
for  the  swarm.  In  the  case  of  electrically-powered  UAVs  where  flight  times  are  already 
limited,  this  factor  becomes  even  more  critical.  For  a  swarm,  the  launching  cycle  needs 
to  be  expeditious.  In  order  to  achieve  this,  the  flow  of  information  and  material  must  be 
streamlined.  For  the  flow  of  information,  there  are  two  primary  categories  to  consider.  The 
first  is  audio  and/or  visual  commands  between  the  launch  crew.  The  second  is  electronic 
data  flow  across  the  launcher’s  sub-systems. 

Time  lost  during  the  launching  sequence  will  have  a  significant,  negative  impact  on  the 
swarming  operation.  Miscommunication  during  a  swarm  launching  sequence  presents  a 
significant  risk  to  mission  success.  To  mitigate  this,  standardized  communications  and  crew 
training  are  required.  Likewise,  data  transfer  delays  between  the  sub-systems  will  have  a 
similar  impact.  Any  interruption  in  the  data  flow  will  potentially  reduce  the  availability  of 
the  launching  system.  Slow  networking  will  have  the  same  effect. 

The  flow  of  material  is  another  aspect  to  consider.  Moving  large  numbers  of  aircraft  into 
position  will  require  some  level  of  pre-staging  to  have  them  readily  available  for  launch  as 
needed.  Automated  sensing  may  be  required  to  help  expedite  the  process.  This  element  of 
launching  a  swarm  should  not  be  overlooked. 

In  addition  to  timing  constraints,  there  are  also  manpower  concerns  to  take  into  account. 
The  number  of  persons  required  to  launch  UAVs  typically  increases  with  the  number  of 
aircraft.  One  of  the  key  benefits  of  swarming  behavior  is  the  reduced  demand  on  operators 
and  technicians.  From  a  manning  perspective,  this  advantage  would  be  nullified  if  it  re¬ 
quired  excessive  manpower  to  launch.  Great  consideration  must  be  taken  when  designing 
the  human  systems  interface  to  minimize  the  demand  on  personnel. 

To  date,  launching  a  UAV  has  been  approached  in  much  the  same  way  as  launching  manned 
aircraft.  Options  include  a  conventional  runway,  catapult  launch,  vertical  takeoff,  and  in 
the  case  of  lightweight  micro  aerial  vehicles  (MAVs),  such  as  those  shown  in  Figure  1 .4 
and  Figure  1.5,  hand-launching  is  also  an  option. 

For  swarms,  the  mission  set  and  the  configuration  of  the  UAV  are  what  defines  which 
method  of  launch  is  best  suited.  Short-range  swarming  missions  that  do  not  require  high 
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Figure  1.4:  Wasp  MAV  (AeroVironment),  Figure  1.5:  Black  Widow  MAV  (AeroVi- 

from  [18]  ronment),  from  [18] 


levels  of  maneuverability  are  well-tailored  to  quad  copter-like  UAVs.  For  these  vertical 
take-off  and  landing  (VTOL)  aircraft,  launching  is  merely  an  exercise  in  adding  power. 
This  is  convenient,  because  it  does  not  require  prepared  surfaces  or  additional  equipment 
to  launch. 

Runways  are  another  alternative  to  launching  swarms.  They  are  a  convenient  launching 
means  as  they  pre-exist  all  over  the  world,  and  they  are  already  capable  of  handling  high 
volumes  of  aircraft.  Runways  eliminate  many  reliability  concerns  because  there  are  not 
moving  parts.  The  downside  is  that  they  require  the  UAV  to  have  a  landing  gear,  which  adds 
weight  and  complexity.  Also,  they  are  geographically  fixed.  Operations  are  not  possible 
outside  of  the  effective  swarm  radius  from  the  airport  facility. 

Hand-launching  is  also  a  valid  approach  to  launching  a  swarm  as  it  does  not  require  com¬ 
plex  systems  and  can  be  accomplished  from  anywhere  a  user  can  stand.  However,  it  only 
suits  a  narrow  range  of  UAVs  and  mission  sets.  Depending  on  the  size  of  the  swarm,  ad¬ 
ditional  personnel  may  be  necessary  to  complete  the  launching  cycle  in  order  to  mitigate 
operator  fatigue.  In  cases  where  several  hundred  or  more  airborne  units  are  required  or 
needed,  hand-launching  becomes  impractical.  Also,  this  method  places  a  considerable  size 
and  weight  restriction  on  the  UAV.  While  they  do  not  have  to  be  as  small  as  the  MAVs 
previously  shown,  anything  over  a  few  pounds  will  become  cumbersome.  There  are  also 
safety  concerns  with  propellers  being  in  close  proximity  to  the  user. 
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The  final  option,  and  the  one  of  interest  to  this  research,  is  the  use  of  a  catapult-type  launch¬ 
ing  system.  For  the  purposes  of  this  study,  a  launcher  will  be  considered  as  any  system  or 
group  of  systems  external  to  the  UAV  that  transfers  kinetic  energy  to  the  aircraft  for  takeoff. 
While  catapult  launchers  are  usually  the  most  complex  solution  of  the  options  discussed, 
they  alleviate  many  of  the  issues  present  in  the  prior  alternatives. 

•  Depending  on  the  design,  they  can  be  based  on  multiple  platforms  including  ships, 
land  vehicles,  and  even  other  aircraft. 

•  Launching  systems  allow  fixed-wing,  non-VTOL  UAVs  to  launch  without  prepared 
surfaces. 

•  They  are  capable  of  being  highly  mobile,  and  are,  theoretically,  able  to  safely  launch 
an  unlimited  number  of  UAVs. 

•  UAV  launchers  are  customizable  to  virtually  any  mission  or  UAV  platform,  making 
them  highly  versatile. 
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CHAPTER  2: 

Systems  Engineering  Approach 


Launching  systems  are  available  in  many  forms,  and  they  are  frequently  customized  for 
specific  aircraft  platforms  and  missions.  From  an  engineering  perspective,  customization 
is  an  advantage  in  that  it  allows  for  tailored  solutions.  However,  it  is  also  a  disadvantage 
because  there  can  exist  a  general  lack  of  continuity  in  design  approach.  The  one-off  nature 
combined  with  the  newness  of  the  market  means  it  is  difficult  to  capture  previous  develop¬ 
ment  efforts  and  systematically  evaluate  best  practices.  These  challenges  were  mitigated 
through  the  use  of  an  established  systems  engineering  (SE)  baseline  approach  and,  when 
necessary,  adaptive  methods  to  complement  the  uniqueness  of  the  design  process. 

Systems  Engineering  is  used  to  ensure  “the  effective  development  and  delivery  of  capability 
through  the  implementation  of  a  balanced  approach  with  respect  to  cost,  schedule,  perfor¬ 
mance,  and  risk”  [19].  There  are  multiple  valid  approaches,  and  each  has  its  own  merits. 
Approaches  are  optimized  for  everything  from  software  design  to  corporate  structure.  For 
this  effort,  it  was  desired  to  adhere  to  the  Department  of  Defense  (DOD)  guidelines  as  pre¬ 
scribed  in  the  Defense  Acquisition  Guidebook  (DAG),  Chapter  4  [19].  The  guide  lends 
itself  well  to  developmental  systems  like  the  one  in  this  study,  and  it  also  adheres  to  the 
accepted  terminology  prevalent  in  existing  DOD  acquisition  programs. 

Figure  6.1  shows  an  adaptation  of  the  inverted  V  model  for  SE.  The  process  originates  at 
the  top  left  of  the  V  with  a  perceived  operational  need  identified  by  the  warfighter.  This 
need  is  then  decomposed  into  elements  that  ultimately  define  the  architecture  design  re¬ 
quired  to  satisfy  stakeholder  needs.  Once  materiel  solutions  are  developed  or  sourced  for 
the  product,  the  realization  phase  commences  with  the  development  and  testing  of  proto¬ 
types.  The  end  goal  of  these  tests  is  to  progressively  transition,  validate,  verify,  integrate, 
and  implement  a  product  that  performs  in  the  desired  operational  environment  prior  to  de¬ 
livery.  The  operational  testing  phase  is  intended  to  test  usability  and  suitability.  One  should 
also  note  the  bridge  occurring  during  each  phase  of  realization  pointing  back  to  the  decom¬ 
position  side.  These  continually  occurring  checks  during  the  product  development  phase 
help  ensure  that  identified  requirements  are  being  met.  Throughout  the  entire  evolution, 
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Figure  2.1:  DOD  SE  Process  Overview,  from  [19] 


technical  management  processes  are  executed. 

While  this  is  a  baseline  for  all  DOD  SE,  these  processes  are  scaled  and/or  modified  ac¬ 
cording  to  the  needs  of  the  design  effort.  For  example,  systems  of  low-complexity  with 
proven  technology  do  not  demand  the  same  depth  of  study  when  compared  to  the  design  of 
a  highly  complex,  developmental  system.  This  chapter  will  address  the  first  two  elements 
in  the  decomposition  process:  Operational  Need  and  System  Requirements. 


2.1  Operational  Need 

Following  the  SE  practices  previously  outlined,  the  design  effort  commenced  with  building 
an  understanding  of  the  operational  needs  for  the  Advanced  Robotic  Systems  Engineering 
Laboratory  (ARSENL). 
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2.1.1  Problem  Definition 

This  research  is  in  direct  support  of  an  operational  need  defined  by  the  ARSENL  lab  at 
Naval  Postgraduate  School  (NPS).  However,  many  of  the  findings  are  applicable  to  other 
swarming,  unmanned  aerial  vehicle  (UAV)  systems.  The  current  goal  for  the  ARSENL 
team  is  to  execute  a  50  versus  50  air  war  using  fully  autonomous,  swarming  UAVs.  Their 
chosen  airframe  is  the  Zephyr  II  shown  in  Figure  2.2. 


Figure  2.2:  Zephyr  II  UAV 


This  is  a  six-pound,  electrically-powered  flying  wing  that  is  modified  to  include  integrated 
avionics  and  advanced  sensing  capabilities.  The  airframe  and  electrical  components  are, 
for  the  most  part,  well-documented,  commercially  available  items.  However,  the  ARSENL 
team  is  at  the  forefront  of  utilizing  these  UAVs  in  a  swarming  capacity.  This  unique  ap¬ 
plication  required  the  team  to  modify  and  develop  highly  complex  hardware,  software,  and 
human  integration  solutions. 

ARSENL’ s  standing  method  for  launching  the  Zephyr  II  aircraft  has  been  the  use  of  a 
bungee-type  system,  shown  in  Figure  2.3.  This  launching  system  utilizes  a  bungee  that  is 
anchored  approximately  50  feet  from  a  set  of  PVC  launch  rails.  The  bungee  is  manually 
retrieved  and  pulled  under  tension  to  the  location  of  the  aircraft  on  the  rails.  Attachment  to 
the  UAV  is  achieved  by  sliding  a  metal  ring  onto  a  hook  anchored  in  the  underside  of  the 
aircraft’s  wing.  A  launch  crewmember  then  holds  the  aircraft  under  tension  until  launch  is 
desired  and  he  or  she  releases  the  aircraft. 

To  date,  the  ARSENL  team  has  used  this  system  to  successfully  launch  12  aircraft  that 
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Figure  2.3:  Zephyr  II  Launch  System 


were  simultaneously  airborne.  However,  it  is  incapable  of  achieving  the  necessary  launch 
rate  to  rapidly  deploy  a  mission-capable  swarm  of  50  UAVs.  To  satisfy  their  operational 
requirements,  a  different  launching  solution  is  required. 


2.1.2  Capability  Gaps 

The  first  step  in  the  requirement  generation  process  is  to  identify  issues  -  or  capability  gaps 
-  in  the  current  solution.  To  this  end,  the  design  team  observed  ARSENL’s  operational  use 
of  their  bungee  launching  solution  and  recognized  the  following  list  of  system  deficiencies: 

•  Operating  at  a  sustainable  pace,  it  took  the  launch  crew  between  one  and  1.5  minutes 
to  retrieve  the  bungee  and  reset  for  launch.  If  attempting  to  launch  50  aircraft,  the 
full  evolution  would  consume  50  to  75  minutes.  The  Zephyr  II  battery  endurance 
is  only  45  minutes,  which  means  that  the  first  aircraft  airborne  is  landing  prior  to 
commencement  of  the  swarm  mission. 

•  The  launching  system  requires  a  minimum  crew  of  two  in  order  to  operate:  One 
crewmember  to  retrieve  the  launching  bungee,  and  one  to  position  and  hold  the  air¬ 
craft  while  the  bungee  is  attached.  The  method  is  labor  intensive  and  impractical  for 


14 


higher  numbers  of  aircraft.  Also,  it  consumes  valuable  human  assets  where  auto¬ 
mated  solutions  are  viable. 

•  The  crewmember  responsible  for  holdback  of  the  aircraft  is  in  close  proximity  to 
the  propeller  of  the  UAV.  Also,  he  or  she  is  in  the  direct  path  of  a  highly-tensioned 
elastic  band.  Failure  of  the  bungee,  its  anchor,  or  inadvertent  throttle  commands  to 
the  UAV  presents  significant  risk  to  this  individual. 

•  Penetrable  ground  in  which  an  anchor  may  be  driven  is  required  at  the  launching  site 
to  secure  the  bungee.  Heavy  weights  of  some  sort  are  conceivably  viable  options 
when  operating  off  of  concrete  or  hard  surfaces,  but  this  has  yet  to  be  implemented. 
Also,  the  weight  required  to  provide  enough  frictional  holding  force  would  likely 
be  cumbersome  to  position  and  relocate.  Therefore,  a  different  anchoring  method  is 
required  to  facilitate  multi-surface  compatibility. 

•  A  shift  in  the  wind  direction  requires  a  time-consuming  process  to  re-anchor  the 
bungee  and  subsequently  realign  the  launch  rails.  If  this  were  to  occur  mid-launch 
cycle,  it  would  effectively  scrub  the  mission.  This  process  must  be  accelerated  and 
simplified. 

Having  defined  the  problem  and  identified  capability  gaps  in  ARSENL’s  existing  launcher 
technology,  the  process  pivots  towards  the  establishment  of  requirements. 


2.2  System  Requirements 

Requirements,  at  the  highest  level,  dictate  what  the  solution  must  “do”  to  satisfy  the  opera¬ 
tional  needs  of  the  stakeholder.  As  system  decomposition  continues  below  the  operational 
level,  more  requirements  are  created  that  define  the  necessary  system  performance  and 
functionality  [19].  On  a  fundamental  level,  requirements  should  be  traceable,  well-defined, 
and  easily  measurable.  Traceability  ensures  there  is  clarity  as  to  why  the  requirement  ex¬ 
ists.  To  promote  traceability  in  this  document,  requirements  are  listed  at  the  conclusion  of 
each  subsection,  linking  them  to  the  origin.  “Well-defined”  implies  that  there  is  no  ambigu¬ 
ity  in  what  the  requirement  states.  Any  reader  should  clearly  understand  the  statement  and 
threshold  value  for  each  requirement.  Finally,  measurement  of  requirements  is  mandated 
in  order  to  verify  and  validate  the  system  during  testing  phases.  This  enables  objective 
measurements  of  system  success  to  conclude  whether  or  not  the  system  is  performing  in 
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accordance  with  the  requirements.  These  measures  are  defined  in  the  concluding  section  of 
this  chapter.  The  final  result  of  these  efforts  should  be  a  clear  understanding  of  the  system 
requirements  necessary  to  meet  stakeholder’s  objectives  and  operational  needs.  Starting  at 
the  highest  level,  the  desires  of  the  stakeholders  are  analyzed. 


2.2.1  Stakeholder  Requirement  Analysis 

Stakeholders  are  the  players  who  are  affected  by,  or  have  an  interest  in,  the  design  project. 
Usually,  stakeholders’  needs  contradict  each  other,  and  this  is  a  tradeoff  process  where 
inputs  are  quantified  and  scaled  to  determine  the  best  course  of  action.  However,  for  a 
small-scale  project  with  a  single  customer,  the  analysis  is  simplified.  Because  the  ARSENL 
team  was  both  the  customer  and  the  end  user  with  a  unified  vision  for  the  design,  many  of 
the  difficulties  typical  of  stakeholder  analysis  are  alleviated.  Collectively,  the  ARSENL 
team  desired  the  following  system  characteristics: 

•  The  solution  should  be  capable  of  the  cycle  rate  required  to  support  50  aircraft  si¬ 
multaneously  airborne  with  a  30-minute  combat  endurance. 

-  The  Zephyr  II  UAV  has  an  endurance  of  approximately  45  minutes.  This  dic¬ 
tates  that  all  aircraft  are  launched  in  15  minutes  for  the  desired  combat  en¬ 
durance.  This  equates  to  a  launch  rate  of  one  aircraft  every  18  seconds. 

•  The  portability  and  setup  procedure  should  allow  for  no  more  than  two  technicians 
to  unload  and  setup  the  system. 

-  If  the  solution  is  to  be  physically  lifted  out  of  the  trailer,  this  translates  into  a 
weight  restriction  on  the  launcher.  If  the  solution  exceeds  a  reasonable  lifting 
threshold,  wheel  and  ramp  combinations  should  be  incorporated  to  accomplish 
the  same  end-goal. 

•  Safety  for  the  user  must  be  ensured. 

-  The  overall  safety  of  the  system  encompasses  multiple  aspects  that  relate  to 
transportation,  setup,  and  operational  concerns.  While  all  are  valid  and  should 
be  addressed,  the  stakeholder’s  primary  concern  is  that  of  operational  safety. 
Launcher  systems  of  any  nature  involve  the  rapid  transfer  of  potential  energy 
to  kinetic  energy.  Regardless  of  how  that  potential  energy  is  stored,  this  poses 
a  safety  concern  to  those  in  the  vicinity  of  the  system.  It  can  be  likened  to  a 
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cocked  bow,  a  pressurized  air  cylinder,  or  a  tensioned  bungee.  Each  of  these 
examples  would  require  safety  measures  to  ensure  user  protection  should  me¬ 
chanical  failure  occur.  Also,  it  follows  that  users  should  be  alerted  as  to  the 
status  of  the  system.  Returning  to  the  example  of  a  pressurized  cylinder,  vi¬ 
sual  inspection  cannot  determine  the  state  of  pressurization.  This  information 
needs  to  be  communicated  to  the  user  so  that  interactions  with  the  system  are 
appropriate,  according  to  the  launcher  status.  Additionally,  system  reliability  is 
a  determining  factor  in  ensuring  user  safety. 

•  The  footprint  should  be  minimized  for  transportation. 

-  ARSENL’s  trailer  is  16  feet  long,  and  is  also  used  to  transport  most  of  their 
support  equipment,  including  the  UAVs.  The  launching  solution  should  allow 
for  continued  use  of  this  trailer  until  other  factors  (such  as  increasing  swarm 
size)  dictate  the  necessity  for  a  higher  volume  transportation  method. 

•  Wind  shifts  should  not  impact  mission  success. 

-  The  reasoning  behind  this  desire  was  discussed  as  one  of  the  capability  gaps  in 
ARSENL’s  existing  launcher.  However,  the  actual  time  required  to  reorient  the 
system  was  not  explicitly  stated.  For  an  initial  threshold,  15  seconds  was  con¬ 
sidered  a  reasonable  time  for  the  system  to  undergo  a  90-degree  reorientation. 

•  Expenses  should  be  justified  for  the  afforded  functionality. 

-  There  was  not  an  explicit  budget  stated  at  the  onset  of  this  design  effort.  When 
development  commenced,  estimated  costs  were  reviewed  with  the  stakeholders 
and  approved  on  a  rolling  basis.  Not  long  after  the  development  of  a  proof- 
of-concept  (POC),  specific  funding  was  received  for  $10,000.  This  became  the 
budget  going  forward. 

•  Commercial,  off-the-shelf  (COTS)  components  should  be  utilized  to  the  maximum 
extent  possible. 

-  From  the  viewpoint  of  the  stakeholder,  using  commercial,  off-the-shelf  (COTS) 
components  reduces  risk,  simplifies  procurement  and  maintenance,  and  has  the 
potential  to  reduce  costs.  It  does,  however,  present  a  challenging  integration 
problem  for  the  design  team  to  harmoniously  merge  components  that  were  not 
originally  designed  to  interact. 

•  The  system  should  be  backwards  compatible  with  ARSENL’s  current  launcher.  Also, 
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physical  modifications  to  the  UAV  are  not  desired. 

-  Developmental  systems  often  take  a  significant  amount  of  time  to  fully  test  and 
integrate  into  an  existing  operation.  ARSENL  does  not  want  to  heavily  modify 
portions  of  their  UAV  fleet  to  accommodate  a  new  launching  system.  Also,  if 
the  system  were  to  fail,  backwards  compatibility  with  their  existing  launcher 
allows  for  flight  tests  to  continue. 

Stakeholder  desires  are  translated  into  high-level  requirements,  or  objectives,  for  the  sys¬ 
tem.  These  objectives  span  across  multiple  categories  of  requirements,  but  all  are  key  to 
high-level  system  success.  Each  requirement  is  categorized  and  measured  at  the  conclusion 
of  this  chapter. 

High-Level,  Stakeholder  Requirements 

1.  The  system  shall  be  capable  of  launching  50  aircraft  within  15  minutes. 

2.  The  system  shall  be  configured  such  that  a  maximum  number  of  two  technicians 
are  able  to  setup  the  launcher  in  15  minutes  or  fewer. 

3.  The  system  shall  demonstrate  a  failure-to-launch  rate  of  less  than  or  equal  to 
one  percent. 

4.  The  system  shall  provide  a  means  of  alerting  the  user  to  system  status  and  po¬ 
tentially  unsafe  conditions. 

5.  The  system  shall  be  shorter  than  16  feet  to  accommodate  transportation  in  AR¬ 
SENL’  s  trailer. 

6.  The  system  shall  be  capable  of  reorienting  90  degrees  in  less  than  or  equal  to 
15  seconds. 

7.  The  prototype  developmental  costs  shall  not  exceed  $10,000. 

8.  The  system  shall  utilize  no  more  than  five  custom  components. 

9.  The  system  shall  not  require  an  alteration  of  the  UAV  in  such  a  way  as  to  make 
it  unusable  with  the  legacy  launcher  system. 

It  should  be  noted  that,  while  this  analysis  fully  represents  the  primary  requirements  of  the 
ARSENL  team,  it  is  not  meant  to  be  a  complete  documentation  of  stakeholder  design  pref¬ 
erences.  The  design  process  introduces  multiple  decision  points  where  alternative  selection 
is  brought  to  the  stakeholder  for  preference. 
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2.2.2  Scope  and  Boundaries 

It  is  important  to  define  the  boundaries  in  a  system  design  process  to  ensure  that  it  is  not 
expanding  beyond  the  solution  needed  to  solve  the  problem.  Likewise,  defining  the  scope 
ensures  the  project  is  not  so  narrow  that  it  does  not  fully  address  the  problem.  Additionally, 
there  should  be  an  understanding  of  the  various  interactions  affecting  the  system.  A  context 
diagram  is  an  effective  visual  tool  to  aid  in  all  three  of  these  processes. 

Observing  the  context  diagram  shown  in  Figure  2.4,  the  boundaries  of  the  design  effort  are 
contained  within  the  central  “UAV  Launching  System”  box.  The  various  entities  surround¬ 
ing  the  central  box  are  not  within  the  scope  of  this  design;  however,  this  does  not  imply  that 
they  are  not  integral  to  the  system’s  operation.  Each  entity  must  interface  with  the  launcher 
when  either  information  or  material  is  exchanged. 
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Figure  2.4:  Launcher  Context  Diagram 

In  some  cases,  the  external  entities  are  inflexible  or  beyond  the  control  of  a  design  team. 
The  launching  environment  is  an  example  that  falls  under  this  category.  For  this  type  of  in¬ 
terface,  the  system  must  be  engineered  to  the  requirements  dictated  by  that  interface.  Other 
interactions,  such  as  the  interface  with  the  ground  control  station  (GCS),  are  more  flexible. 
Compatibility  is  still  required  for  system  operation,  but  the  GCS’s  code  or  data  transfer 
methods  may  be  modified  to  suit  the  launcher’s  design.  For  ease  of  reference,  the  external 
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systems  highlighted  in  dark  blue  are  considered  inflexible.  The  systems  highlighted  in  light 
blue  represent  the  more  flexible  entities.  For  clarity,  a  detailed  description  of  each  interface 
follows. 

Environment  The  environment  in  which  the  launcher  must  operate  dictates  the  level  of 
environmental  protection  that  is  required  of  the  design.  Also,  the  environment  de¬ 
termines  the  surfaces  from  which  the  launcher  must  be  operated.  Considerations  for 
environmental  conditions  such  as  dust,  wind,  rain,  and  temperature  should  be  noted. 
The  ARSENL  team  currently  operates  at  a  UAV  testing  facility  in  central  California. 
For  this  location,  there  is  a  significant  amount  of  airborne  particulate.  This  warrants 
consideration  for  any  contact  components  such  as  bearings  or  slides.  Also,  electrical 
equipment  may  require  some  form  of  filtration  or  barrier  where  fans  are  the  primary 
cooling  source.  When  launching  aircraft,  wind  direction  relative  to  the  launcher’s 
orientation  is  a  critical  variable.  Directional  shifts  in  the  wind  are  not  uncommon 
for  the  testing  facility;  therefore,  it  is  reasonable  to  predict  that  the  launcher  may  re¬ 
quire  reorientation  during  a  launch  sequence.  Although  the  ARSENL  team  does  not 
currently  operate  in  the  rain,  it  may  prove  advantageous  to  provide  some  level  of  wa¬ 
terproofing  in  the  event  of  light,  passing  showers.  Finally,  the  ambient  temperature 
in  this  region  is  moderate;  hence  overheating  or  freezing  concerns  are  not  predicted 
to  be  an  issue. 

Transportation  Trailer  Transportation  of  the  launcher  is  a  critical  piece  to  consider  be¬ 
cause  it  has  a  significant  impact  on  usability.  The  ARSENL  team  utilizes  a  16-foot, 
enclosed  trailer  when  traveling  to  and  from  the  launch  site.  The  length  of  this  trailer 
dictates  the  maximum  allowable  length  for  the  launching  solution. 

UAV  The  launcher  must  provide  sufficient  energy  for  launch,  and  transfer  that  energy  to 
the  aircraft.  Also,  there  may  be  data  transfer  considerations  between  the  launcher  and 
the  UAV.  ARSENL’s  standing  procedure  is  to  manually  conduct  final  flight  checks 
with  the  UAV  on  the  launch  rails.  With  higher  rates  of  launch  expected  for  swarm 
mission  sets,  there  may  be  a  need  for  partial  or  full  automation  of  this  process. 

GCS  The  role  of  the  GCS  during  launch  has  been  rapidly  evolving  as  the  team’s  swarming 
capability  advances.  Because  of  this,  the  exact  level  or  type  of  interaction  is  unknown 
and  will  likely  evolve  over  time.  However,  the  current  expectation  is  that  communi¬ 
cation  will  between  the  GCS  and  the  launcher.  For  this,  the  launcher  will  require  the 
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ability  to  send  and  receive  data  over  the  GCS  network. 

ARSENL  Launch  Crew  The  launching  crew  is  the  primary  consideration  for  human  fac¬ 
tors  integration.  The  crew  should  be  highly  comfortable  interfacing  with  the  design. 
This  dictates  that  the  system  is  intuitive,  safe,  reliable,  and  provides  the  necessary 
communication  to  alert  users  of  safe  or  unsafe  conditions.  Also,  it  should  incorpo¬ 
rate  friendly  ergonomics  for  transportation,  setup,  and  use. 

ARSENL  Lab  Team  The  ARSENL  lab  team  will  be  constructing  the  launcher  once  it  is 
out  of  prototype  phase.  Additionally,  they  will  be  responsible  for  maintenance  ac¬ 
tions  over  the  lifecycle  of  the  system.  A  design  that  utilizes  COTS  solutions  to  the 
maximum  extent  possible  greatly  simplifies  both  processes.  Likewise,  effort  should 
be  given  to  reducing  the  number  of  components  that  require  maintenance  and  ensur¬ 
ing  accessibility  for  those  that  do.  Last,  but  perhaps  the  most  important,  building  a 
highly  reliable  system  with  minimal  downtime  will  greatly  benefit  this  interface. 

Intuitively,  most  of  the  requirements  defined  in  this  subsection  are  related  to  system  inter¬ 
face  compliance.  They  are  shown  in  the  order  presented. 

Environmental  Requirements 

1.  The  system  shall  be  capable  of  reorienting  90  degrees  in  less  than  or  equal  to  15 
seconds.  (This  requirement  is  restated  for  completeness,  but  it  was  also  stated 
as  a  stakeholder  requirement.) 

2.  The  system  shall  be  capable  of  sensing  wind  speed  and  direction. 

3.  The  system  shall  be  waterproofed  so  that  light  rain  showers  will  not  damage 
any  component  on  the  system. 

4.  The  system  shall  be  securable,  if  needed,  to  both  permeable  and  non-permeable 
surfaces. 

5.  Any  components  of  the  system  that  are  subject  to  degraded  performance  as  a 
result  of  airborne  particulate  shall  be  sealed. 

Transportation  Requirements 

1.  The  system  shall  be  shorter  than  16  feet  to  accommodate  transportation  in  AR¬ 
SENL’  s  trailer.  (This  requirement  is  restated  for  completeness,  but  it  was  also 
stated  as  a  stakeholder  requirement.) 

2.  The  system  shall  be  capable  of  transportation  through  a  standard- width  door- 
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way  of  36  inches  without  disassembly. 

UAV  Interface  Requirements 

1.  The  system  shall  be  capable  of  providing  an  aircraft  exit  velocity  of  35  MPH. 

2.  The  system  shall  be  capable  of  supporting  wireless  data  transfer  with  the  UAV. 

3.  The  system  shall  provide  a  method  of  UAV  attachment  for  the  launch  cycle. 

4.  The  system  shall  provide  a  method  of  UAV  release  at  the  completion  of  the 
launch  cycle. 

5.  The  force  on  the  UAV’s  launch  hook  shall  not  exceed  20  pounds.  (This  was  the 
maximum  force  exerted  on  the  hook  by  ARSENL’s  legacy  launcher.) 

GCS  Interface  Requirements 

1 .  The  system  shall  be  capable  of  supporting  two-way  wireless  data  transfer  with 
GCS. 

ARSENL  Human  Interface  Requirements 

1.  The  system  shall  provide  a  means  of  alerting  the  user  to  system  status  and  po¬ 
tentially  unsafe  conditions.  (This  requirement  is  restated  for  completeness,  but 
it  was  also  stated  as  a  stakeholder  requirement.) 

2.  The  system  shall  utilize  no  more  than  five  custom  components.  (This  require¬ 
ment  is  restated  for  completeness,  but  it  was  also  stated  as  a  stakeholder  re¬ 
quirement.) 

3.  The  system  shall  demonstrate  a  failure-to-launch  rate  of  less  than  or  equal  to  1 
percent. 


2.2.3  Operational  Scenarios 

Operational  scenarios  are  designed  to  aid  in  the  identification  of  required  system  function¬ 
ality.  “An  up-to-date  Concept  of  Operations  (CONOPS)  for  the  system  is  basic  to  under¬ 
standing  the  system  context,  notably  mission  and  task  threads  and  data  exchanges  that  have 
an  impact  on  the  system”  [19]. 

Two  scenarios  are  outlined  to  present  the  probable  use-cases  for  the  ARSENL  team.  First, 
the  responsibilities  of  each  team  member  are  reviewed  to  clarify  the  scenarios.  These 
roles  are  changing  as  capabilities  progress,  but  the  descriptions  are  not  expected  to  differ 
significantly  over  the  course  of  system  development. 
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Mission  Commander  The  mission  commander  is  responsible  for  oversight  of  the  entire 
testing  evolution.  This  individual  coordinates  the  efforts  of  the  team  and  offers  assis¬ 
tance  or  guidance  where  required. 

Safety  Coordinator  This  position  ensures  adherence  to  safety  protocol.  To  avoid  distrac¬ 
tion,  this  individual  does  not  aid  in  any  other  processes.  Should  an  unsafe  situation 
develop,  it  is  his  or  her  responsibility  to  initiate  corrective  action.  All  team  members 
share  the  authority  and  responsibility  to  identify  and  correct  unsafe  practices,  but  the 
coordinator  is  a  fail-safe  should  any  element  be  overlooked. 

GCS  Operator  This  person  or  persons  is  monitoring  the  data  link  between  the  aircraft  and 
the  GCS.  (They)  are  responsible  for  conducting  pre-flight  verification  of  the  UAV’s 
automated  systems  and  ensuring  the  aircraft  are  functioning  as  programmed  through¬ 
out  mission  execution.  He  or  she  is  not  always  within  line-of-sight  of  the  launching 
location;  therefore,  communication  with  launch  crews  has  historically  been  estab¬ 
lished  via  verbal  relay. 

Swarm  Commander  The  swarm  commander  monitors  the  swarm  as  a  whole.  His  or  her 
responsibility  is  to  monitor  and  control  the  swarm’s  behavior  throughout  the  mission. 

Development  Engineer  This  crewmember  is  available  on  standby  to  provide  debugging 
services  during  the  test  should  data  link  or  software  issues  arise. 

Flight  Crew  Chief  The  crew  chief  oversees  all  ground  operations  involving  the  UAVs. 
He  or  she  is  coordinating  the  efforts  of  the  aircraft  commander,  the  flight  preparation 
technician,  and  the  launch  technician. 

Aircraft  Commander/Safety  Pilot  This  role  is  likely  temporary,  but  is  currently  in  place 
to  manually  override  autopilot  inputs  should  the  situation  dictate.  The  aircraft  com¬ 
mander  closely  monitors  all  aircraft  for  the  first  few  seconds  after  launch  until  the 
autopilot  engages.  He  or  she  will  then  remain  on  standby  throughout  the  mission. 

Flight  Preparation  Technician  This  position  prepares  all  UAVs  for  the  mission.  This 
includes  coordination  with  the  GCS  operators  during  autopilot  initiation,  systems 
check  of  the  aircraft,  and  pre-staging  of  the  aircraft. 

Faunch  Technician  The  launch  technician  is  responsible  for  executing  the  UAV  loading 
process  required  for  launch.  He  or  she  will  be  directly  interacting  with  the  launching 
platform  and  transferring  aircraft  from  the  staging  location  to  the  launcher.  This 
individual  is  also  the  final  approval  authority  who  commands  the  system  to  launch. 
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If  all  aircraft  are  pre- staged  for  launch,  the  flight  preparation  technician  will  also  aid 
the  transference  of  aircraft. 

Scenario  One  -  Single  Launcher  For  this  scenario,  a  single  launcher  is  utilized  to  launch 
the  entire  salvo  of  swarming  UAVs.  The  launch  technician  unloads  the  system,  and 
transports  it  to  the  desired  launching  location.  The  technician  then  prepares  the 
launching  system  for  operations  by  performing  whatever  setup  is  required. 

Once  operational,  a  series  of  checks  is  conducted  to  ensure  proper  functionality  of 
the  launcher.  These  checks  likely  commence  with  a  visual  inspection  of  critical  com¬ 
ponents  and  one  or  more  dry  launches  (if  feasible)  to  check  mechanical  soundness. 
Depending  on  the  connectivity  of  the  system,  data  links  are  confirmed  between  the 
GCS  and  launcher,  as  well  as  the  launcher  and  the  UAV. 

With  sound  functionality,  the  flight  preparation  technician  conducts  pre-flight  checks 
and  UAV  staging.  Using  a  single  launcher,  the  pre-stage  setup  is  critical  to  mission 
success.  All  50  UAVs  need  to  be  within  reasonable  distance  of  the  system  and  ready 
for  launch  to  facilitate  rapid  loading.  This  task  would  benefit  from  the  aide  of  an 
automated  process,  but  such  a  system  has  yet  to  be  developed;  therefore,  it  is  assumed 
that  UAVs  are  manually  loaded  onto  the  launching  system  by  a  technician. 

Once  the  first  aircraft  to  be  launched  is  pre- staged  on  the  launcher,  the  GCS  oper¬ 
ator,  swarm  commander,  and  flight  crew  chief  confirm  all  systems  are  functional. 
The  launch  technician  then  ensures  the  aircraft  commander  is  ready  and  initiates  the 
launch.  With  one  aircraft  airborne,  the  system  is  manually  or  automatically  reset  to 
prepare  for  the  next  UAV. 

Either  the  flight  preparation  or  launch  technician  then  retrieves  and  loads  the  next 
UAV.  Systems-up  status  is  assumed  with  the  GCS  and  swarm  commander  after  initial 
launch.  For  all  subsequent  launches,  the  launch  technician  only  confirms  with  the 
aircraft  commander  for  launch  coordination.  At  any  point  during  this  evolution,  any 
member  of  the  crew  is  free  to  pause  the  launching  process  or  cancel  the  mission.  This 
procedure  repeats  for  the  remaining  48  aircraft. 

For  wind  shifts  outside  of  crosswind  limitations,  the  system  is  reoriented.  Depending 
on  the  design,  this  is  manually  executed,  remotely  commanded,  or  automatic.  If 
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automated,  measures  are  taken  to  ensure  the  direction  chosen  by  the  system  is  free  of 
obstacles  and  personnel. 

If  the  launcher  is  located  in  the  aircraft  recovery  area,  it  needs  to  be  relocated  prior  to 
mission  completion.  Any  member  under  the  flight  crew  chief  accomplishes  this  task. 
At  the  conclusion  of  testing,  the  system  is  deactivated  and  reloaded  into  the  trailer. 

Scenario  Two  -  Multiple  Launchers  For  the  second  scenario,  multiple  launchers  are 
considered.  This  could  be  as  few  as  two,  but  as  many  as  50;  one  for  each  UAV. 
While  the  scenarios  begin  with  the  unloading  of  the  launch  platform(s),  it  should  be 
noted  that  transportation  of  multiple  launchers  is  expected  to  increase  the  total  sys¬ 
tem  footprint.  The  only  case  where  this  would  not  hold  true  is  if  the  use  of  multiple 
launchers  afforded  a  reduction  in  the  physical  size  of  each  unit.  A  potential  realiza¬ 
tion  of  this  scenario  is  the  use  of  multiple  bungee-type  systems  similar  to  the  one 
currently  utilized. 

The  same  setup  procedures  as  outlined  in  Scenario  One  are  accomplished,  but  a  trade¬ 
off  occurs  during  this  phase.  It  either  requires  more  personnel  to  support  the  setup 
of  multiple  launchers,  or  it  requires  more  time  for  a  single  individual  to  perform  the 
task.  This  decision  is  up  to  the  flight  crew  chief,  but  pulling  manpower  for  launcher 
setup  likely  delays  flight  preparation  of  the  UAVs.  Whatever  the  choice,  this  is  a 
more  demanding  task  on  personnel  than  setting  up  a  single  launcher. 

The  benefit  afforded  by  this  procedure  is  that  pre-staging  is  simplified.  Assume, 
for  this  portion  of  the  discussion,  that  50  launchers  are  utilized.  This  allows  for 
all  aircraft  to  be  staged  onto  their  respective  launchers  and  standing  by  for  takeoff. 
Where  a  technician  was  previously  required  to  load  each  aircraft  during  the  launch 
sequence,  there  is  now  a  free  individual  standing  by  to  aid  in  other  requirements 
during  the  launch. 

The  same  system  confirmations  occur,  followed  by  launch  initiation  down  the  array 
of  launch  systems.  For  this  scenario,  the  launch  technician  is  solely  responsible  for 
initiating  launch.  The  flight  preparation  technician  loads  aircraft  onto  the  launching 
systems  on  a  ready  basis. 

If  a  wind  change  occurs  mid-launch  cycle,  it  is  increasingly  complex  to  reorient  the 
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launchers,  depending  on  how  many  are  utilized.  A  wind  shift  that  is  90  degrees  out 
is  cause  for  a  complete  reorientation  of  an  abreast  array,  because  launchers  are  now 
propelling  aircraft  directly  into  the  launcher  that  is  upwind  and  adjacent.  Some  sort 
of  terminal  area  forcast  (TAF)  requirement  may  be  necessary  to  predict  future  wind 
direction  at  the  desired  time  for  launch  to  mitigate  this  issue.  Takedown  proceeds  as 
it  did  in  Scenario  One,  but  with  additional  manning  requirements. 

The  requirements  that  originated  from  this  section  are  the  result  of  stakeholders’  feedback 
after  reviewing  the  scenarios.  Their  preference  was  Scenario  One,  that  is,  conduct  deploy¬ 
ments  with  a  single  launcher.  At  most,  two  launchers  were  considered  acceptable  to  support 
the  multi-launcher  scenario. 

Operational  Requirements 

1.  The  solution  shall  not  include  more  than  two,  independent  launcher  systems. 

2.  The  solution  shall  be  designed  such  that  a  single  operator  is  able  to  load  the 
UAV. 

2.2.4  Functional  Analysis 

The  purpose  of  functional  analysis  is  to  identify  the  required  functionality  that  satisfies 
all  requirements.  The  chosen  functions  should  be  in  direct  support  of  the  requirements 
discussed  in  this  chapter.  A  functional  decomposition  diagram  was  used  to  graphically 
present  the  system  in  a  logical,  hierarchical  breakout  for  clarity.  The  highest-level  function 
is  that  of  the  system  as  a  whole,  which  then  expands  down  as  various  sub-functions  are 
examined.  For  the  purpose  of  this  research,  only  the  top  three  levels  of  functions  were 
desired  for  analysis.  This  was  considered  to  be  a  reasonable  level  of  detail  to  adequately 
define  a  prototype  development  effort.  The  decomposition  is  shown  in  Figure  2.5. 

1.0  Launch  Swarming  UAVs  This  is  the  highest  level  of  functionality,  and  it  includes  all 
required  functions  of  the  launcher  system. 

1.1  Provide  Launching  Force  This  function  requires  the  launcher  to  provide  a  means  of 
generating  the  force  required  for  UAV  launches. 

1.1.1  Provide  Power  To  support  the  ability  to  provide  an  adequate  launching  force, 
the  system  must  include  a  means  of  generating  that  energy. 

1.1.2  Transfer  Power  With  the  energy  provided  as  dictated  in  Function  1.1.1,  the 
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Figure  2.5:  Launcher  Functional  Decomposition 


system  has  to  transfer  said  energy  into  usable  power. 

1.2  Secure  UAV  The  system  must  provide  a  method  of  securement  for  the  UAV  during 

launch. 

1.2.1  Attach  with  UAV  At  the  onset  of  launch,  the  UAV  must  be  securely  attached 
to  the  launching  system. 

1.2.2  Release  UAV  At  completion  of  the  power  transfer  function,  the  system  must 
then  release  the  UAV  for  flight. 

1.3  Communicate  Though  the  degree  of  integration  is  not  yet  known,  the  system  will 

require  functionality  to  communicate  with  various  external  systems. 

1.3.1  Report  Status  The  system  will  contain  the  means  to  report  current  status.  This 
may  include  the  ready  state  of  the  launcher,  the  UAV’s  state,  or  perhaps  main¬ 
tenance  status  of  various  components. 

1.3.2  Receive  Orders  This  functionality  is  not  limited  to  receiving  data  based  or¬ 
ders.  It  also  includes  physical  orders  that  the  system  may  receive.  An  example 
of  this  would  be  the  launch  technician  throwing  a  switch  to  command  launch. 

1.4  Monitor  The  launcher  will  be  operated  in  a  rapidly  changing  environment  with  various 

system  states  that  must  be  monitored  for  operation. 

1.4.1  Monitor  Environment  The  launching  of  UAVs  requires  that  certain  environ¬ 
mental  parameters  are  monitored  to  ensure  safe  launching  conditions  exist.  The 
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launching  system  will  be  required  to  provide  this  functionality. 

1.4.2  Monitor  Internal  Status  There  should  be  some  level  of  internal  monitoring 
built  into  the  system  to  facilitate  the  alerting  of  users  if  a  degraded  or  unsafe 
state  exists.  Likewise,  the  same  monitor  would  provide  confirmation  that  the 
launcher  is  functioning  correctly. 


2.2.5  Requirement  Definition 

As  previously  stated,  the  purpose  of  this  work  buildup  is  to  develop  a  set  of  requirements 
for  the  system.  Some  requirements  originated  directly  from  stakeholders,  while  others 
were  derived  to  help  support  the  identified  interactions  and  operational  concepts  for  the 
system.  There  are  multiple  approaches  to  selecting,  classifying,  and  measuring  system  re¬ 
quirements.  For  this  study,  this  was  accomplished  through  the  establishment  of  measures  of 
effectiveness  (MOE),  measures  of  performance  (MOP),  functional  thresholds,  and  system 
constraints. 

MOEs  are  used  to  evaluate  high-level,  operational-related  measures  that  evaluate  key  sys¬ 
tem  requirements.  The  specific  definition  of  a  MOE  can  vary  depending  on  the  application. 
For  clarity,  the  characteristics  used  in  this  study  will  be  outlined.  The  attributes  are  defined 
in  the  Air  Force’s  SMC  Systems  Engineering  Primer  and  Handbook  [20]: 

•  relates  to  performance 

•  simple  to  state 

•  complete 

•  states  any  time  dependency 

•  states  any  environmental  conditions 

•  can  be  measured  quantitatively  (if  required,  may  be  measured  statistically  or  as  a 
probability) 

•  easy  to  measure 

MOPs,  as  the  name  implies,  are  performance-related  measures  that  evaluate  lower-level 
functionality  of  the  system.  One  or  more  MOPs  will  frequently  support  a  single,  higher- 
level  MOE.  They  can  also  be  stand-alone  measures  to  define  system  interface  requirements 
or  sub-system  performance  standards.  Functional  requirements  are  sometimes  subject  to 
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objective  thresholds,  but  for  this  study,  they  were  all  evaluated  based  on  Boolean  true  or 
false  measures. 

Constraints  are  limit-based  requirements  that  define  non-performance  based  qualities  of 
the  system  (e.g.,  weight,  volume,  dimension,  cost)  [21].  These  may  also  relate  to  design 
constraints  such  as  the  stakeholder’s  desire  for  COTS  components  and  backwards  compat¬ 
ibility  of  the  system. 

Tables  2. 1-2.3  represent  the  summation  of  all  identified  requirements.  They  are  broken 
into  high-level,  performance,  functional,  and  constraint  requirement  categories.  As  noted 
in  Section  2.2.1,  high-level  requirements  (R1-R9)  were  based  on  stakeholders’  desires  - 
which  encompass  multiple  sub-categories. 

The  requirements  relating  to  automation,  network  integration,  and  sensing  were  listed  for 
completeness,  but  are  not  discussed  as  part  of  this  report.  This  includes  (R5),  (R14),  and 
(R15).  For  detailed  information  on  the  satisfaction  of  these  requirements,  refer  to  [22]. 
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Table  2.1:  System  Requirements  (High-Level) 

High-Level  Requirements 

Requirement  Requirement  Description  Measure  Measures  Measure  Description  Units  of  Measure  Objective  / 
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feet  to  accommodate  transportation 
in  ARSENL’s  trailer. 

The  prototype  developmental  costs  CON  4  Expense  Cost  Constraint  U.S.  Dollar  <10,000 

shall  not  exceed  $10,000. 


Table  2.2:  System  Requirements  (Performance  and  Functional) 

Performance  Requirements 

Requirement  Requirement  Description  Measure  Measures  Measure  Description  Units  of  Measure  Objective  / 
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ot  UAV  attachment  tor  the  launch  Capability 

cycle 

R17  The  system  shall  provide  a  method  FUN  6  UAV  Detachment  Interface  True /False  True 

of  UAV  release  at  the  completion  of  Capability 

the  launch  cycle. 


Table  2.3:  System  Requirements  (Constraints) 

Constraint  Requirements 

Requirement  Requirement  Description  Measure  Measures  Measure  Description  Units  of  Measure  Objective/ 
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CHAPTER  3: 
Market  Evaluation 


The  final  task  of  the  decomposition  phase  is  to  research  potential  solutions  and  determine 
if  a  ground-up  design  effort  is  warranted.  For  ease  of  reference,  the  systems  engineering 
(SE)  diagram  is  presented  again  in  Figure  3.1. 


Systems  Engineering 


Operational 
Need 


c 


>  Delivered 
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Technical  Management  Processes 


•  Requirements  Management 

•  Risk  Management 

•  Configuration  Management 


■  Technical  Data  Management 

■  Interface  Management 


Enables  a  balanced  approach  for  delivering  capability  to  the  warfighter 


Figure  3.1:  DOD  SE  Process  Overview,  from  [19] 


Activities  that  were  performed  during  this  phase  included  market  research  and  an  analysis 
of  alternatives  (AoA).  These  efforts  are  intended  to  aid  in  the  identification  of  the  following 
pieces  of  information: 

Market  Research 

•  It  is  possible  that  previously  undiscovered  products  currently  exist  that  are  ca¬ 
pable  of  satisfying,  or  coming  close  to  satisfying,  the  system  requirements.  If 
this  is  the  case,  the  design  process  is  greatly  simplified  or  eliminated  altogether. 
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•  Understanding  similar  systems  promotes  the  identification  of  desirable  and  un¬ 
desirable  system  traits  based  on  design  requirements. 

•  Market  research  helps  to  build  a  broad  understanding  of  the  engineering  tech¬ 
niques  that  may  be  required  during  a  design  process. 

Analysis  of  Alternatives 

•  If  multiple  solutions  are  found  to  exist,  the  AoA  process  develops  a  set  of  stan¬ 
dards  to  determine  the  optimal  solution. 

•  Alternatively,  this  process,  combined  with  system  requirements,  builds  the  stan¬ 
dards  required  to  determine  if  commercial  solutions  are  not  viable.  If  this  de¬ 
termination  is  made,  a  baseline  design  effort  is  warranted. 


3.1  Market  Research 

The  original  intent  of  this  research  was  to  conduct  a  full,  world-wide  survey  of  existing 
unmanned  aerial  vehicle  (UAV)  launchers.  Various  entities  in  both  industry  and  DOD  sec¬ 
tors  publish  similar  documents  on  the  UAVs  themselves;  however,  no  such  document  is 
believed  to  exist  for  launchers.  During  the  research  effort  to  accomplish  this,  language 
barriers  and  a  general  lack  of  documentation  required  a  reduction  of  scope.  To  remedy 
this,  the  study  is  limited  to  include  only  well-documented  launchers  utilized  or  developed 
by  U.S.  industry,  academic  institutions,  or  the  DOD.  Also,  this  market  study  is  not  in¬ 
tended  to  be  an  all-inclusive  list  of  available  solutions.  Rather,  the  desire  is  to  conduct  a 
search  broad  enough  to  build  the  aforementioned  knowledge  base  of  existing  UAV  launcher 
technologies. 

A  few  conclusions  are  immediately  apparent  as  result  of  the  study.  There  is  a  general 
lack  of  information  available  for  UAV  launching  systems.  This  is  primarily  attributed  to  a 
low  degree  of  innovation  in  the  designs.  As  a  result  of  this,  there  is  not  a  high  degree  of 
competition  in  the  market.  It  appears  the  general  stance  is  that,  if  the  aircraft  platform  is 
safely  launched,  the  launcher  is  acceptable  and  does  not  warrant  further  discussion.  The 
primary  selling  point  for  commercial  UAV  manufacturers  is  the  UAV  itself;  the  launcher  is 
bundled  as  a  ground  support  item.  The  limited  cases  for  which  comprehensive  information 
is  available  are  for  the  few  companies  producing  launchers  compatible  with  multiple  UAV 
platforms.  Their  marketing  strategies  lead  to  the  second  conclusion:  the  market  is  not  yet 
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responding  to  swarming  UAV  scenarios.  Frequently  highlighted  features  of  an  advertised 
system  are  its  ease  of  setup  and  portability.  This  is  likely  because  these  two  variables 
greatly  affect  the  versatility  and  ease-of-use  of  the  UAV.  However,  parameters  critical  to 
swarming  scenarios,  like  UAV  loading  and  system  reset  times,  are  rarely  mentioned. 

The  first  phase  of  the  research  effort  is  accomplished  by  identifying  UAV  platforms  that 
were,  and  are  currently,  in  use  by  the  U.S.  Search  engine  results  were  compiled  into  a 
spreadsheet  where  each  UAV  was  then  individually  studied  to  determine  its  method  of 
launch.  A  total  of  156  UAV  platforms  were  examined.  Of  those  platforms,  43  utilize  some 
form  of  identified  launching  method.  The  remaining  UAVs  are  either  out  of  service,  so 
poorly  documented  that  the  launching  method  could  not  be  determined,  utilized  a  runway 
for  takeoff,  or  were  vertical  take-off  and  landing  (VTOL)  systems. 

The  research  was  then  re-directed  to  specifically  target  launcher  systems.  In  some  cases, 
launchers  are  not  aircraft-specific;  ergo  this  aided  in  identifying  cross-platform  systems. 
Nine  additional  UAV  launchers  were  identified.  Some  of  these  systems  are  developed  in 
other  countries  but  available  for  purchase  through  U.S.  distributors;  therefore,  they  were 
included. 

Finally,  active  UAV  research  laboratories  linked  to  various  academic  institutions  were  ex¬ 
plored.  Results  from  24  identified  universities  with  UAV  programs  revealed  that  only  two 
are  engaged  in  a  targeted  study  of  UAV  launcher  technologies.  The  other  facilities  that 
utilized  a  UAV  launcher  as  part  of  their  research  have  acquired  commercial  systems. 

Prior  to  discussing  specific  results,  the  limitations  of  the  survey  should  be  understood.  Due 
to  the  previously  noted  lack  of  data  available,  many  systems  are  categorized  based  only 
on  physical  appearance  or  video-recorded  launch  sequences.  In  the  case  of  hydraulic  sys¬ 
tems,  the  appearance  and  operation  is  very  similar  to  that  of  pneumatic.  For  this  reason, 
all  systems  using  a  piston  setup  were  classified  as  pneumatic.  Also,  the  method  of  research 
does  not  accurately  reflect  the  abundance  of  bungee-type  launching  systems.  When  tar¬ 
geting  launchers  used  for  specific  UAV  airframes,  bungee  systems  are  only  counted  once. 
However,  their  simplicity  and  ease  of  adaptability  to  light  and  medium- weight  UAVs  allows 
them  to  be  utilized  for  multiple  platforms.  Additionally,  because  bungee  systems  are  gener¬ 
ally  inexpensive  and  can  easily  be  constructed  with  minimal  hand  tools,  they  are  frequently 
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used  without  any  formal  documentation.  Finally,  the  historic  abundance  of  rocket-assisted 
take-off  (RATO)  type  systems  returned  too  many  results  to  be  fairly  compared  against  more 
modern  bungee  and  pneumatic  solutions.  To  remedy  this,  only  current  or  recently  (within 
10  years)  active  pyrotechnic  launchers  are  considered. 

For  a  summary  of  results,  the  above  constraints  are  implemented,  and  the  percentages  of 
each  type  of  system  represent  the  fraction  with  respect  to  those  actually  using  a  launch¬ 
ing  system.  Hand-launched  UAVs  are  removed  from  the  study.  Results  show  that  more 
than  half  of  the  explored  market  employed  some  variation  of  a  pneumatic  system.  Bungee 
systems  are  the  second  most-frequently  used  launch  system  at  approximately  18  percent, 
but  this  is  not  believed  to  be  an  accurate  reflection  of  their  widespread  use.  Pyrotechnic 
systems  are  the  third  most  prevalent,  followed  by  the  two  testing  platforms  designed  for 
carrier  use.  These  values  are  shown  in  Table  3.1. 


Table  3.1:  Summary  of  Market  Results 


Parameter 

Data 

Number  of  Entities  Researched 

188 

Number  Using  Launching  Systems  /  Not  Hand-Launched 

27 

Percent  Using  Pneumatic 

62.96% 

Percent  Using  Bungee 

18.52% 

Percent  Using  Pyrotechnic 

11.11% 

Percent  Using  Aircraft  Carrier 

7.41% 

Using  the  parameter  breakdown  shown  in  Table  3.1,  various  design  features  are  discussed 
in  the  following  sections.  The  high  degree  of  commonality  allows  for  an  abbreviated 
overview;  therefore,  rather  than  address  each  launcher  individually,  sample  systems  are 
selected  from  each  parameter  class,  with  the  exception  of  the  aircraft  carrier  catapult,  to 
represent  the  frequently  observed  engineering  features. 

Pneumatic 

The  Arcturus  Portable  launching  system,  when  assembled,  is  a  175-pound  aluminum  and 
composite  pneumatic  launcher  [23].  The  system  features  a  nitrogen  or  compressed  air  ac¬ 
cumulator  attached  directly  to  the  launching  tube.  When  launch  is  desired,  a  pull  chord 
is  activated  that  allows  the  pressurized  gas  to  transfer  into  the  launch  tube.  A  launch  rod 
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resides  inside  the  launch  tube  and  is  attached  to  the  UAV.  The  rod  is  accelerated  by  the  ex¬ 
panding  gas  and  ejected  from  the  system.  Shortly  after  ejection,  the  rod  falls  and  separates 
from  the  UAV  and  lands  a  few  feet  from  the  assembly.  There  is  no  mention  of  an  included 
compressor,  hence  it  is  assumed  that  multiple  accumulator  bottles  or  separate  compressor 
systems  would  be  used  for  multiple  launch  scenarios.  This  system  is  shown  in  Figure  3.2. 


Figure  3.2:  Arcturus  Portable  Launching  System,  from  [23] 


The  UAV  Factory  Pneumatic  launcher  is  available  in  both  6  and  12  kJ  power  options  [24]. 
These  launchers  are  also  highly  portable  and  can  be  broken  down  into  a  hardened  suitcase 
for  transportation.  They  are  remotely  activated  for  launch  where  high-pressure  air  is  vented 
into  the  departure  end  of  the  launch  rail.  A  pulley  at  the  departure  end  transfers  the  energy 
from  an  internal  plunger  to  the  UAV  cradle  via  cables.  At  completion  of  the  launch  stroke, 
the  UAV  cradle  is  arrested  and  pressure  is  vented.  The  included  compressor  refills  tanks 
in  approximately  10  and  20  minutes  for  the  6  and  12  kJ  versions  respectively  [24].  This 
system  is  shown  in  Figure  3.3 

With  the  exception  of  a  few  novel  approaches,  these  two  examples  are  fair  representations 
of  the  common  setups  observed  for  lightweight  pneumatic  launchers.  For  heavier  pneu¬ 
matic  systems  (up  to  several  tons  in  weight),  the  structure  is  significantly  more  complex, 
but  the  implementation  and  mechanical  configuration  of  the  launching  section  are  of  similar 
design. 
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Figure  3.3:  UAV  Factory  Pneumatic  Launchers  (6  and  12  kg),  from  [24] 

Bungee  Systems 

Two  basic  types  of  bungee  systems  were  found.  The  first  was  identical  to  the  design  cur¬ 
rently  used  by  Advanced  Robotic  Systems  Engineering  Laboratory  (ARSENL).  It  con¬ 
sisted  of  a  set  of  PVC  or  aluminum  launch  rails  with  a  bungee  anchored  at  some  distance 
from  the  rails.  The  only  variation  on  this  design  was  that  some  included  a  foot-pedal  op¬ 
erated  bungee  holdback  fitting  to  avoid  having  to  manually  hold  the  aircraft  in  place  under 
tension.  For  brevity,  this  type  of  system  will  not  be  re-presented. 

The  second  type  functioned  similarly  to  the  light-weight  pneumatic  systems  using  a  series 
of  pulleys  to  propel  the  UAV  but  retain  the  cradle.  An  example  of  this  is  produced  by 
Air- Vision- Air.  The  catapult  is  capable  of  delivering  enough  force  to  launch  a  13-pound 
aircraft  at  25  mph  [25].  The  cradle  is  retained  post  launch,  and  the  user  then  redirects  the 
bungees  over  the  pulleys  and  manually  retracts  the  cradle  to  re-apply  tension.  This  system 
is  shown  in  Figure  3.4. 
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Figure  3.4:  AVA  Bungee  Launcher,  from  [25] 


Pyrotechnic  Systems 

There  were  only  two  current  or  recently  active  pyrotechnic  systems  found.  The  first  one  to 
be  discussed  is  the  launching  system  of  the  RQ-5  Hunter.  The  RQ-5  was  co-developed  by 
Israel  Aerospace  Industries  (IAI)  and  TRW  (now  Northrup  Grumman),  and  was  used  by 
the  United  States  Army  starting  in  1996  [26].  More  modem  iterations  of  this  platform  have 
since  been  developed,  and  it  is  unclear  if  they  still  employ  RATO  launching  capabilities. 
Though  limited  data  were  available  for  the  original  launcher,  it  appears  to  be  a  simplistic 
system  consisting  only  of  a  launch  platform  to  direct  the  UAV  during  rocket  ignition.  This 
system  is  shown  in  Figure  3.5. 


Figure  3.5:  RQ-5  Flunter  RATO  Launch,  from  [26] 
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The  second  pyrotechnic  system  found  was  the  launcher  for  the  AeroVironment  Switchblade 
UAV.  The  switchblade  is  still  under  development  at  the  time  of  writing,  but  it  represents 
a  noteworthy  advancement  in  launcher  mobility  and  compactness.  Though  the  details  of 
functional  operation  are  not  known,  the  launcher  appears  to  operate  in  a  fashion  similar  to 
mortars.  The  UAV’s  wings  fold  to  fit  inside  the  tube  and  expand  upon  exit.  The  system  is 
shown  in  Figure  3.6. 


Figure  3.6:  Switchblade  Tube  Launch,  from  [27] 


3.2  Analysis  of  Alternatives 

To  conduct  an  AoA,  a  launcher  classification  system  was  developed  to  aid  in  the  target¬ 
ing  of  systems  with  desirable  characteristics.  For  example,  an  aircraft  carrier’s  catapult 
system  is  deemed  out-of-scope  because  it  significantly  exceeds  the  aircraft  weight  require¬ 
ments  necessary  for  a  six-pound  UAV.  The  classification  system  shown  in  Table  3.2  was 
conceived  over  the  course  of  research  from  observed  characteristics  of  existing  launching 
systems  and  probable  future  configurations. 
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Table  3.2:  UAV  Launcher  Classification 


Category 

Characteristic 

Selected  Within  Scope 

Bungee/Spring 

X 

Pneumatic 

Hydraulic 

X 

Power  Generation 

Electromechanical 

Electromagnetic 

Pyrotechnic 

X 

Self/Gravity 

X 

Direct/Guided 

X 

Power  Transfer 

Pulley 

T  A  rm 

X 

Y 

Lever  Arm  X 

Projectile 


Small  Group  1  (<  20) 

X 

Medium  Group  2  (21  -  55) 

X 

UAV  Weight  Range  (Pounds) 

Large  Group  3  (<  1320) 
Larger  Group  4  (>1320) 
Largest  Group  5  (>1320) 

Human  Carried 

X 

Human  Portable 

X 

Mobility 

Self-contained 
Vehicle  Towed/Mounted 
Stationary 

X 

The  column  on  the  left  denotes  the  category;  the  center  column  shows  the  various  charac¬ 
teristics  that  define  a  launching  system  within  each  category;  and  the  column  on  the  right 
indicates  whether  or  not  the  launcher  was  considered  to  be  within  scope  for  the  AoA.  If 
alternative  solutions  are  well  outside  of  system  requirements,  they  are  eliminated  from  fur¬ 
ther  analysis.  An  “X”  indicates  the  characteristic  is  considered  within  scope  and  included 
for  study. 

The  power  generation  category  is  used  to  differentiate  launching  systems  based  on  how 
they  store  potential  energy.  The  power  transfer  category  shows  the  frequently  found  meth¬ 
ods  for  energy  transfer  or  amplification  of  the  launching  force  or  velocity.  The  aircraft 
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weight-range  for  which  the  launching  system  was  designed  is  considered  the  best  method 
for  determining  power  available.  Depending  on  the  type  of  power  generation  utilized,  it 
was  found  that  power  was  frequently  documented  using  metrics  that  were  difficult  to  com¬ 
pare.  For  example,  pneumatic  systems  may  list  the  pressure  ratings  for  the  cylinder  while 
electromechanical  systems  list  motor  power  in  watts  or  horsepower.  Also,  depending  on 
how  the  energy  is  transferred,  the  power  actually  transferred  to  the  aircraft  can  vary  greatly. 
To  use  a  consistent  unit  of  measure,  the  DOD-defined  weight  categories  for  a  UAV’s  maxi¬ 
mum  gross  takeoff  weight  is  used  [28].  To  avoid  confusion,  it  should  be  mentioned  that  the 
determining  difference  for  a  Group  4  and  Group  5  UAV  is  maximum  cruising  altitude,  not 
weight.  The  last  category  addresses  the  mobility  of  the  launching  system. 

A  detailed  description  and  justification  for  in-scope  selection  is  provided  in  the  following 
sections,  but  first,  a  visual  depiction  of  the  terminology  used  aids  in  the  description  discus¬ 
sion.  It  contains  the  major  components  common  to  many  launchers.  The  actual  design  and 
integration  of  these  components  varies  greatly,  but  the  core  functionality  remains  the  same. 
Figure  3.7  is  a  computer-aided  design  (CAD)  image  generated  using  SOLIDWORKS  soft¬ 
ware  of  a  sample  UAV  launching  section.  From  this  point  forward,  all  referenced  CAD 
images  were  created  using  SOLIDWORKS  software.  Also,  some  components  of  the  as¬ 
semblies  shown  in  the  CAD  are  sourced  from  the  McMaster-Carr  database  [29]. 


Figure  3.7:  Common  Launcher  Components 

The  component  names  were  created  according  to  the  preferences  of  this  author,  but  they 
share  terminology  and  were  inspired  by  aircraft  carrier  catapult  systems.  The  “launch  rail” 


42 


is  the  portion  of  the  launcher  that  directs  the  aircraft  during  launch.  The  “shuttle”  is  the 
component  guided  by  the  launch  rail  that  interfaces  with  the  cradle.  The  “cradle”  phys¬ 
ically  holds  the  UAV  in  place.  In  some  cases,  the  shuttle  and  the  cradle  are  the  same 
component.  Finally,  the  “retainer”  is  the  device  responsible  for  stopping  the  shuttle  at  the 
end  of  the  launch  stroke.  With  an  understanding  of  the  basic  terminology  used  for  this 
section,  Table  3.2  will  be  explained. 

1.  Type  of  Power  Generation 

Bungee/Spring  Bungee  or  spring  systems  store  the  required  energy  for  launch  by 
physical  compression  or  extension  of  the  elastic  component.  They  are  typically 
inexpensive,  lightweight,  and  relatively  simple  to  implement.  Using  ARSENL’s 
existing  launcher  as  an  example  of  the  simplicity,  this  system  does  not  require 
a  shuttle  or  retainer.  For  these  reasons,  bungee  and  spring  systems  are  included 
for  the  study. 

Pneumatic  Pneumatic  systems  are  found  to  be  the  most  common.  They  utilize  com¬ 
pressed  air  to  generate  the  necessary  launching  force.  Due  to  the  prevalence  of 
these  types  of  systems,  they  are  included  for  study. 

Hydraulic  Hydraulic  launchers  are  less  common  than  pneumatic,  and  they  have 
higher  pressure  requirements  for  the  hydraulic  fluid  than  their  pneumatic  coun¬ 
terparts.  The  ARSENL  team  wants  to  avoid  the  required  safety  actions  for 
high-pressure  systems,  as  well  as  the  inherent  complexity  to  generate  the  re¬ 
quired  pressure;  therefore,  these  systems  are  not  included  for  study. 

Electromechanical  Electromechanical  systems  use  rotary  or  linear  electric  actua¬ 
tors  for  launching  power.  These  can  be  the  sole  source  of  energy,  or  they  can 
be  used  in  combination  with  bungees  or  springs.  These  systems  are  well  suited 
for  field  use  where  batteries  can  serve  as  the  primary  power  source  without  the 
need  for  a  generator;  hence  they  are  included  for  study. 

Electromagnetic  Electromagnetic  systems  are  essentially  modified  rail  guns  using 
fluctuating  magnetic  fields  to  propel  a  ferrous  shuttle  down  the  launch  rail. 
These  systems  are  highly  complex  and  demand  a  significant  amount  of  elec¬ 
trical  power.  For  these  reasons,  they  are  not  included  in  the  study. 

Pyrotechnic  Pyrotechnic  systems  utilize  a  combustive  compound  to  set  off  a  con¬ 
trolled  explosion  for  propulsion.  This  is  similar  to  a  tube-and-mortar  type  of 
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weapon.  Also,  RATO  used  in  combination  with  a  launch  rail  are  placed  in  this 
category.  The  safety  concerns  and  transportation  issues  with  handling  these 
compounds  are  extensive  and  undesirable  for  this  design.  For  this  reason,  they 
are  not  included  in  the  study. 

Self/Gravity  Self-propelled  systems  use  the  UAV’s  own  power  to  propel  the  aircraft. 
Likewise,  gravity  systems  allow  the  aircraft  to  “slide”  down  a  ramp  to  generate 
velocity.  Both  of  these  concepts  may  be  realized  with  a  relatively  simple  solu¬ 
tion  because  the  launcher  does  not  inherently  store  energy.  For  this  reason,  they 
are  included  for  study. 

2.  Type  of  Power  Transfer 

Direct/Guided  A  direct  or  guided  system  does  not  use  mechanical  advantage  to  pro¬ 
pel  the  UAV.  ARSENL’s  existing  bungee  launcher  is  an  example  of  a  direct- 
launch  system.  Other  examples  of  this  type  of  system  are  self  or  gravity  launch¬ 
ers.  This  type  of  power  transfer  reduces  mechanical  complexity,  which  offers 
advantages  worth  exploring;  therefore,  it  is  included  in  the  study. 

Pulley  Power  transfer  and  amplification  via  pulleys  is  the  most  common  type  of 
setup  found.  In  these  systems,  one  or  more  pulleys  are  utilized  to  create  me¬ 
chanical  advantage  for  the  system.  Pulley  systems,  in  contrast  with  lever  arms, 
allow  for  inline  orientation  with  the  launch  rail,  which  contributes  to  a  reduced 
footprint.  The  abundance  of  existing  systems  and  the  general  compactness  of 
this  power  transfer  method  make  it  worth  including  within  the  scope  of  this 
study. 

Lever  Arm  Lever  arms  accomplish  the  same  end-goal  as  pulley  systems.  They  are 
simply  another  means  of  amplifying  velocity  or  power.  Tradeoffs  between  the 
two  methods  will  be  discussed  further,  but  for  the  purpose  of  market  research, 
this  type  of  system  is  included  as  a  potential  approach. 

Projectile  These  systems  transfer  power  using  a  projectile  that  detaches  from  the 
launch  rail.  The  advantage  of  projectile-type  systems  is  that,  because  the  sled 
detaches,  there  is  no  need  to  stop  it  at  the  end  of  the  launch  stroke,  thus  elimi¬ 
nating  the  retainer  and  associated  impact.  However,  due  to  the  safety  concerns 
inherent  with  uncontrolled  objects  departing  the  launcher,  this  method  is  elimi¬ 
nated  from  study. 
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3.  Aircraft  Weight  Range 

Small  Group  1  (<  20  Pounds)  This  category  of  UAV  is  the  most  applicable  to  the 
design  effort  because  the  Zephyr  II  falls  under  Group  1;  therefore,  it  is  included 
for  study. 

Medium  Group  2  (21  -  55  Pounds)  Although  Group  2  aircraft  are  larger  than  ARSENL’s, 
they  are  still  close  enough  in  weight  that  the  launching  systems  warrants  inclu¬ 
sion. 

Group  3-5  Launcher  systems  designed  for  aircraft  heavier  than  55  pounds  are  not 
included  because  the  complexity  required  is  not  warranted  for  a  six-pound  UAV. 

4.  Mobility 

Human- Carried  Human-carried  systems  are  launchers  light  enough  and  compact 
enough  to  be  lifted  and  transported  by  a  single  individual.  This  meets  the  stake¬ 
holder  requirements  for  mobility;  therefore,  they  are  included. 

Human-Portable  Human-portable  systems  are  launchers  that  are  either  light  enough, 
or  incorporate  appropriate  mechanical  advantage,  for  one  or  two  humans  to  re¬ 
locate.  These  systems  also  meet  the  stakeholder  requirement;  therefore,  they 
are  included. 

Self-Contained  Self-contained  mobility  is  characterized  by  a  launching  system  that 
has  built-in  power  for  relocation.  It  became  ambiguous  to  differentiate  between 
self-contained  and  vehicle-mounted  launchers.  To  mitigate  the  issue,  a  total  sys¬ 
tem  weight  threshold  of  500  pounds  is  arbitrarily  established  for  self-contained 
systems.  The  on-board  power  source  for  mobility  allows  for  a  single  individual 
to  relocate  these  launchers;  therefore,  they  are  included  for  study. 

Vehicle  Towed/Mounted  These  systems  are  either  towed  by  a  vehicle,  or  designed 
to  be  mounted  to  a  vehicle.  A  “vehicle”  includes  ships,  land  units,  and  other 
aircraft.  They  are  not  included  for  study  because  these  systems  exceed  the 
requirements  to  be  transported  inside  ARSENL’s  trailer. 

Stationary  Stationary  units  are  permanently  mounted  on  location.  There  are  not 
any  examples  of  this  type  of  launcher  found,  but  there  is  potential  for  them 
to  be  implemented  at  some  point  in  the  future.  An  example  of  this  may  be 
a  system  similar  to  an  air  defense  missile  silo  where  UAVs  are  launched  as 
the  defensive  countermeasure.  This  type  of  launcher  utilization  was  outside  of 
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the  stakeholders’  requirements,  and  there  are  not  current  examples.  For  these 
reasons,  it  is  not  considered  for  further  study. 

Using  these  metrics  to  narrow  the  acceptable  results  found  in  the  market  survey,  only  three 
systems  remain.  They  are  the  Lockheed  Martin  Stalker,  the  UAV  Factory  Pneumatic  Cata¬ 
pult,  and  the  AVA  Bungee  Launcher.  The  Lockheed  Martin  Stalker  is  removed  because  it 
is  an  identical  system  to  ARSENL’s  bungee  launcher.  The  specifications  for  the  remaining 
two  systems  are  shown  in  Table  3.3.  Refer  back  to  Figure  3.3  and  Figure  3.4  for  images  of 
these  launching  systems. 


Table  3.3:  Launcher  Specifications,  after  [24],  [25] 


Specification 

UAV  Factory 

AVA 

Power  Generation 

Pneumatic 

Bungee 

Power  Transfer 

Pulley 

Pulley 

UAV  Weight  Range 

Group  1  and  2 

Group  1 

Mobility 

Human  Portable 

Human  Carried 

Rail  Length 

13.1  feet 

11.2  feet 

Maximum  Launch  Velocity 

53.7  mph 

25  mph 

Launch  Pressure 

145  PSI 

N/A 

Reset  Time 

<10  Minutes 

<  2  Minutes 

Weight 

242.5  Pounds 

58  Pounds 

Of  the  two  options  commercially  available,  neither  is  capable  of  meeting  the  established 
requirements.  The  reset  time  of  the  UAV  Factory  pneumatic  launcher  would  require  that 
40  units  be  deployed  to  meet  launch-cycle  time  requirements.  Also,  utilizing  this  many  of 
their  launchers  would  weigh  approximately  10,000  pounds.  This  far  exceeds  the  trailer’s 
weight  and  space  limitations.  AVA’s  bungee  launcher  would  require  four  launchers  to  meet 
this  same  requirement.  From  a  size  and  weight  perspective,  this  is  feasible  as  the  units  are 
compact  and  lightweight;  however,  the  launcher  is  not  designed  for  automated  reset.  To 
take  advantage  of  the  four-launcher  system,  one  would  need  four  launch  crews  -  one  to 
operate  and  reset  each  system.  ARSENL  does  not  have  the  manpower  to  support  this  many 
launch  crews.  Also,  the  AVA  falls  below  the  required  launch  velocity  of  35  mph  for  Zephyr 
II  UAVs.  Increasing  the  bungee  strength  for  greater  end  velocity  would  likely  require  a 
re-design  of  all  tensioned  components  and  was  not  thought  to  be  practical.  Having  ruled 
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out  the  purchase  of  a  commercial  system,  the  research  necessarily  pivots  towards  design 
and  development  of  a  custom  integrated  launching  system. 
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CHAPTER  4: 
Design  Development 


Concept  generation  is  the  first  step  in  the  physical  design  development  process.  Also,  it 
marks  the  beginning  of  a  transition  period  from  decomposition  to  realization  in  the  systems 
engineering  (SE)  V  model. 

4.1  Concept  Development 

Developing  concepts  is  an  important  phase  in  the  design  process.  The  baseline  solution  for 
an  eventual  prototype  is  created  during  this  effort;  therefore,  it  is  critical  the  process  be  fully 
inclusive.  All  possibilities  should  be  examined  with  equal  consideration.  The  purpose  of 
the  process  is  to  exhaustively  explore  potential  solutions  and  then  select  the  best  candidate 
for  further  development.  For  this  thesis,  concepts  are  eliminated  or  selected  based  primarily 
on  the  following  two  criteria: 

Satisfaction  of  Requirements  The  concept  needs  to  satisfy  the  stakeholder  requirements 
as  identified  in  Chapter  2.  This  was  not  an  easy  determination  to  make  because  the 
concepts  were  only  basic  drawings  of  potential  solutions.  Without  analytical  data, 
decisions  were  based  on  the  combined  experience  of  the  Advanced  Robotic  Systems 
Engineering  Laboratory  (ARSENL)  team,  stakeholder  feedback,  and  the  author’s 
extensive  background  in  lightweight,  remotely-piloted  aircraft. 

Design  Simplicity  This  is  a  key  limitation  and  factor  to  consider  during  concept  genera¬ 
tion.  Simplicity  was  also  important  to  the  stakeholder  as  a  predictor  for  future  relia¬ 
bility.  In  general,  lowering  the  complexity  of  a  system  tends  to  have  a  positive  impact 
on  the  reliability.  Also,  the  solution  had  to  be  developed  within  the  manufacturing 
and  technical  limitations  of  just  two  individuals.  In  addition  to  this  thesis,  a  parallel 
effort  to  design  and  build  the  required  automation  and  sensing  capabilities  necessary 
for  the  mechanical  solution  to  function  is  presented  in  [22]. 

4.1.1  Previous  Work 

The  concept  generation  phase  was  influenced  by  previous  work  completed  as  part  of  a 
Naval  Postgraduate  School  (NPS)  capstone  design  team.  This  was  a  seven-person  group 
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working  to  achieve  the  same  launching  capability  for  the  ARSENL.  The  lessons  learned 
are  directly  applicable  to  the  concept  development  phase  and  should  be  discussed. 

The  design  featured  a  pneumatic  actuator  connected  to  a  lever  arm  for  mechanical  advan¬ 
tage.  The  prototype  was  named  “RULE”  for  Rapid  UAV  Launch  Engine.  The  computer- 
aided  design  (CAD)  image  is  shown  in  Figure  4.1. 


Retainer 


Pneumatic  Actuator 


Launch  Rail 


Shuttle  /  Linear 
Rearing 


Lever  Arm 


Cradle 


Figure  4.1:  Schematic  of  the  Rapid  UAV  Launch  Engine  Prototype 

An  external  air  compressor  provided  pressure  for  the  system,  and  an  electronically  con¬ 
trolled  solenoid  was  used  to  remotely  trigger  launch.  The  velocity  of  the  pneumatic  rod 
was  amplified  4:1  using  a  lever  arm  for  mechanical  advantage.  This  energy  was  transferred 
to  a  linear  bearing  with  the  unmanned  aerial  vehicle  (UAV)  cradle  attached.  At  completion 
of  the  launch  stroke,  position  sensors  shut  off  the  pressure,  and  the  retaining  spring  stopped 
the  shuttle  assembly.  The  UAV  departed  the  cradle  as  a  result  of  the  rapid  deceleration.  Re- 
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set  was  accomplished  by  providing  low-pressure  air  to  the  opposite  side  of  the  pneumatic. 
A  picture  of  the  completed  prototype  is  shown  in  Figure  4.2. 


Figure  4.2:  Photograph  of  the  RULE  Prototype  during  Outdoor  Experiments 


4.1.2  Lessons  Learned 

The  RULE  prototype  was  unable  to  provide  the  necessary  velocity  for  launch.  However,  it 
was  a  valuable  learning  experience  that  provided  a  significant  amount  of  insight  for  future 
design  considerations. 

Engineering  Considerations 

1.  The  use  of  CAD  proved  highly  beneficial.  The  CAD  model  allowed  for  rapid 
design  changes  without  the  need  to  physically  assemble  hardware.  At  the  time 
of  building,  the  system  was  assembled  without  the  need  for  hardware  modifica¬ 
tions. 

2.  While  extruded  aluminum  was  not  the  lightest  framing  option  available,  it  al¬ 
lowed  for  ease  of  construction  and  ease  of  modification  for  design  changes.  It 
also  provided  a  simplistic  approach  to  mounting  various  hardware  components, 
because  no  drilling  was  necessary. 
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3.  The  use  of  precision  components  requires  all  interfacing  parts  to  be  of  equal 
precision.  The  linear  bearing  was  designed  for  a  precision  ground  shaft.  Ground 
shafts  were  not  available  at  the  desired  length;  therefore,  a  welded  stainless 
launch  rail  was  used  instead.  In  order  for  the  linear  bearing  to  freely  slide 
down  the  launch  rail,  its  positioning  plates  had  to  be  loosened  extensively.  This 
resulted  in  a  significant  amount  of  play  between  the  bearing  and  the  rail  and 
undesirable  rocking  in  the  UAV  cradle  assembly. 

4.  The  attempt  to  maximize  the  use  of  commercial,  off-the-shelf  (COTS)  products 
meant  many  components  were  being  implemented  in  unconventional  applica¬ 
tions.  For  example,  a  car  door  lock  was  repurposed  as  the  safety  holdback 
for  the  swing  arm.  This  type  of  component  adaptation  was  expected  for  a  de¬ 
sign  like  this,  and  in  some  cases,  it  was  perfectly  acceptable.  However,  there 
were  several  points  in  the  design  that  were  absorbing  forces  either  in  magnitude 
or  direction  that  exceeded  component  recommendations.  The  consequence  of 
this  was  the  necessity  to  add  bracing  at  several  points  in  the  structure.  Testing 
showed  that  bracing  one  point  usually  led  to  failure  elsewhere  or  more  brac¬ 
ing,  which  leads  to  an  infinite  loop.  The  net  takeaway  for  future  prototypes 
was  to  ensure  COTS  components  that  were  under  load  were  being  stressed  in 
accordance  with  their  specifications. 

5.  All  losses  in  a  system  must  be  accounted  for  when  using  mathematical  mod¬ 
eling  to  size  components.  When  characterizing  the  physical  interactions  of  a 
complex  system,  assumptions  are  usually  made  to  account  for  losses.  While 
the  team  tried  to  error  on  the  side  of  caution,  the  omission  of  key  considerations 
resulted  in  failure  to  reach  required  launch  velocities.  The  focus,  at  the  time  of 
design  conception,  was  on  losses  associated  with  frictional  forces  in  the  swing 
arm  assembly.  This  was  properly  mitigated;  however,  testing  revealed  airflow 
restrictions  from  the  compressor  that  were  not  calculated.  This  resulted  in  low 
flow  rates  that  were  unable  to  fully  power  the  launch  stroke. 

6.  The  location  and  method  of  UAV  engagement  with  the  cradle  was  critical.  Intu¬ 
itively,  this  was  known  to  be  an  important  interface,  but  the  extent  to  which  the 
supporting  structure  could  adversely  affect  the  launch  was  underestimated.  For 
this  particular  setup,  the  cradle  had  a  “V”  cut  in  the  leading  edge  that  would  en- 
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gage  with  two  nylon  bolts  anchored  in  the  UAV’s  wing.  The  bolts  were  located 
on  the  aerodynamic  center.  This  is  approximately  two  inches  aft  of  the  center 
of  gravity.  When  the  launch  stroke  was  complete,  the  intent  was  for  the  nylon 
bolts  to  slide  out  of  the  “V”  with  minimal  effort  and  low  pitching  moments. 
However,  testing  revealed  that  the  friction  between  the  bolt  and  the  cradle  was 
high  enough  that  it  caused  a  nose-down  pitching  moment.  This  resulted  in  the 
UAV  immediately  being  redirected  into  the  ground. 

7.  While  pneumatic  systems  were  the  most  prevalent  in  studies,  these  solutions 
were  not  intended  to  rapidly  reset  for  follow-on  launches.  A  rapid  reset  required 
additional  support  equipment.  The  swarming  scenario  did  not  allow  for  pre¬ 
charged  tanks.  A  tank  large  enough  to  support  50  launches  was  not  practical. 
Therefore,  a  compressor  was  required.  In  total,  the  system  required  both  12- 
and  24- volt  DC  power  supplies  for  the  sensor  suite,  a  120- volt  AC  supply  to 
power  the  compressor,  and  a  compressor.  All  of  this  took  time  to  set  up  and 
required  power  outlets  for  operation.  The  testing  facilities  for  ARSENL  were 
able  to  support  this,  but  it  was  a  cumbersome  process  and  limited  the  launcher’s 
mobility. 

8.  High-speed  video  analysis  showed  the  propeller,  though  unpowered,  wind- 
milled  during  launch.  This  was  previously  an  unknown  occurrence  to  ARSENL 
and  mandated  that  the  propeller  be  secured  for  launch,  or  the  full  arc  be  free 
from  obstruction. 

9.  Energy  absorption  of  the  launch  shuttle  was  a  significant  source  of  stress  on 
the  system.  High-speed  video  showed  both  torsional  and  longitudinal  flexing 
of  the  framing  structure  when  the  shuttle  was  arrested.  Although  a  structural 
failure  did  not  occur  during  testing,  it  was  reasonable  to  conclude  that  repeated 
launches  would  eventually  weaken  the  structure  or  loosen  fasteners.  Fixing  this 
issue  became  a  top  priority  for  future  prototypes. 

Operational  Considerations 

1.  The  RULE  launcher  was  able  to  support  the  cycle  time  requirement  of  one 
launch  every  18  seconds.  The  design  focus  and  enabler  to  accomplishing  this 
target  was  the  automated  reset  function  of  the  launcher.  However,  other  factors 
of  importance  noticed  during  testing  were  actual  loading  times  of  the  UAVs 
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and  crew  coordination.  The  system  was  mechanically  capable  of  being  reset  in 
under  five  seconds,  but  most  of  the  time  between  launches  was  due  to  staging 
times  for  the  UAV  and  communications  between  the  various  operators.  Stream¬ 
lining  this  process  through  automation  or  smart  design  should  be  incorporated 
into  future  prototypes  for  enhanced  performance. 

2.  The  RULE  launcher  required  the  ARSENL  team  to  manually  load  and  run  soft¬ 
ware  from  external  computers  to  manage  the  sensor  suite  and  launching  func¬ 
tions.  From  their  perspective,  this  was  undesirable  and  should  be  redesigned 
internally  to  the  system  with  a  simple  On/Off  switch. 

3.  The  large  footprint  of  the  launcher  took  up  valuable  floor  space  in  the  trailer. 
Launch  velocities  achievable  were  directly  proportional  to  the  length  of  the 
lever  arm.  In  other  words,  to  achieve  higher  velocities,  the  assembly  would 
need  to  be  widened.  This  became  a  logistics  issue  with  transportation. 


4.1.3  Concepts 

In  addition  to  meeting  system  requirements  within  the  engineering  limits  of  the  design 
team,  the  top  priority  going  into  the  concept  development  phase  was  to  design  a  system 
free  from  impact.  The  only  method  seen  in  the  market  study  for  achieving  this  capability 
was  to  utilize  a  projectile-type  launcher  where  the  shuttle  assembly  departs  the  system  after 
the  launch  stroke.  However,  this  method  was  eliminated  as  an  alternative  as  discussed  in 
Section  3.2.  Therefore,  new  approaches  needed  to  be  developed. 

The  first  approach  explored  involved  using  extended  throw  dampeners  to  increase  the  im¬ 
pulse  of  stopping  the  shuttle.  In  the  RULE  design,  a  spring  dampener  was  used  for  this 
purpose.  However,  COTS  springs  with  the  required  spring  coefficient  to  arrest  the  shuttle 
only  compress  a  few  inches.  This  was  too  rapid  of  a  deceleration  to  mitigate  the  effects 
of  an  impact.  In  an  effort  to  promote  simplicity,  the  concept  shown  in  Figure  4.3  used  the 
same  bungee  system  as  both  the  launching  force  and  dampener.  This  eliminated  the  need 
for  additional  dampeners. 

The  concept  utilizes  a  locking  pivot  to  allow  the  bungee  support  beams  to  collapse  for 
transport.  The  launch  rail  is  mounted  above  the  bungee  supports  as  a  floating  sub-assembly 
to  allow  the  shuttle  to  traverse  the  full  20-foot  length  of  the  launch  rail.  Length  was  arbi- 
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Figure  4.3:  Top  View  of  Bungee  Concept 


trarily  determined  as  a  starting  point  based  on  common  launcher  lengths  observed  during 
the  market  analysis. 

Envisioned  operation  would  use  an  electric  winch  to  retract  the  shuttle  to  the  launch  posi¬ 
tion  and  tension  the  bungees.  The  aircraft  would  then  be  mounted  onto  a  cradle  assembly 
and  launch  would  be  achieved  by  releasing  the  winch  holdback.  Maximum  velocity  would 
occur  at  the  mid- stroke  point  (10  feet  down  the  rail)  where  some  type  of  UAV  release  mech¬ 
anism  would  be  required  to  detach  the  UAV.  As  the  shuttle  slides  past  the  mid-point,  the 


55 


bungee  assembly  progressively  rebuilds  tension,  arresting  the  motion.  Major  drawbacks  to 
this  concept  and  the  reasoning  for  cancelling  further  development  were: 

1.  Assuming  the  coefficient  of  friction  between  the  shuttle  and  the  launch  rail  is  low, 
this  system  would  oscillate  for  some  time  following  the  launch  before  coming  to  rest. 
Dampening  the  oscillations  at  an  accelerated  rate  requires  the  addition  of  electrically- 
controlled  brakes,  adding  to  the  complexity. 

2.  While  the  concept  effectively  eliminates  impact,  doing  so  with  this  method  requires 
the  launch  rail  to  be  twice  the  length  desired  for  actual  launch.  This  negatively  im¬ 
pacts  transportation  or,  if  the  rail  were  broken  into  two  sections,  it  would  significantly 
complicate  the  structure. 

3.  From  the  perspective  of  the  launch  technician,  the  shuttle  assembly  is  returning  di¬ 
rectly  at  the  operator  at  a  velocity  near  that  of  launch.  Assuming  safety  concerns  are 
mitigated,  it  was  determined  this  would  likely  be  unsettling  for  the  user. 

4.  Finally,  ARSENL  stakeholders  were  not  in  favor  of  aircraft  release  being  dependent 
on  timing  mechanisms.  It  was  assumed  the  release  would  be  software-based.  Any  lag 
in  processing  performance  or  missed  cues  results  in  a  failure  to  launch.  Additionally, 
failed  launch  on  this  system  meant  the  UAV  is  now  riding  on  a  violent  pendulum 
until  the  oscillations  subdue. 

The  second  concept  considered  was  an  adaptation  of  a  typical  pneumatic  system.  The 
reason  the  capstone  design  team  originally  decided  to  use  a  swing  arm  in  favor  of  pulleys 
was  the  ease  with  which  it  automatically  reset.  All  researched  commercial  systems  using 
pulleys  for  mechanical  advantage  required  manual  reset  once  the  pulley  cables  were  slack 
following  a  launch.  In  some  cases,  the  cables  actually  required  re-routing  back  onto  the 
pulley  assembly  as  the  slack  allowed  them  to  fall  out.  To  mitigate  these  issues,  the  concept 
shown  in  Figure  4.4  was  conceived. 

The  concept  shown  utilizes  two  pneumatics  for  control  of  the  cable  tension  during  launch 
and  reset.  Mechanical  advantage  is  achieved  by  stacking  an  array  of  pulleys  such  that 
one  unit-of-length  change  in  the  pneumatic  results  in  four  units  of  motion  at  the  shuttle 
assembly.  Adding  or  removing  pulleys  in  the  pulley  assembly  alters  this  ratio. 

Envisioned  operation  would  use  electrically-controlled  solenoids  to  simultaneously  retract 
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Figure  4.4:  Side  View  of  Pneumatic  Concept 


the  launching  pneumatic  while  extending  the  retracting  pneumatic.  The  harmonization  of 
the  pneumatics  would  control  cable  tension  throughout  the  launch  stroke.  Also,  the  addition 
of  a  retracting  pneumatic  allowed  for  automatic  reset  of  the  shuttle  assembly.  Logic  could 
be  incorporated  for  the  retracting  pneumatic  to  function  as  the  dampener  at  the  end  of  the 
launch  stroke  to  arrest  the  shuttle  prior  to  impact.  Major  drawbacks  to  this  concept  and  the 
reasoning  for  cancelling  further  development  were: 

1.  Although  this  concept  solves  the  large  footprint  issues  associated  with  the  RULE  de¬ 
sign,  it  does  not  eliminate  the  burdensome  support  equipment  required  for  pneumatic 
systems. 

2.  Core  functionality  of  the  system  requires  the  pneumatics  to  be  perfectly  synchro¬ 
nized.  This  was  thought  to  be  a  highly  complicated  endeavor  that  would  involve 
significant  programming  and  perfectly  mirrored  air  sources.  Given  the  limited  time- 
frame  available  for  development,  it  was  not  thought  to  be  a  viable  option. 

These  two  concepts  were  an  attempt  to  adapt  the  principles  found  during  market  research 
and  the  capstone  effort  to  meet  system  requirements.  There  were  other  variations  not  pre¬ 
sented,  but  they  were  similar  in  concept  with  only  minor  adjustments.  At  this  point  in 
the  concept  development,  it  was  decided  to  depart  from  known  methods  and  approach  the 
problem  from  a  new  perspective.  Rather  than  focus  on  UAV  launching  technology,  the 
scope  was  broadened  to  include  any  system  that  rapidly  accelerated  an  object  from  rest. 

The  augmented  focus  allowed  for  exploration  of  new  systems  like  spring-loaded  throw¬ 
ers  used  for  clay  pigeons  and  roller  coaster  acceleration  methods.  For  the  most  part,  the 
complexity  or  mechanical  setup  of  these  systems  did  not  lend  themselves  well  to  UAV 
launchers.  One,  however,  stood  out  as  viable. 
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Baseball  pitching  machines  operate  on  the  principles  of  inertia  and  friction.  One  or  two  fly¬ 
wheels  are  accelerated  to  desired  velocity,  and  a  relatively  lightweight  baseball  is  inserted 
into  the  mechanism.  The  baseball  is  then  compressed  against  the  flywheel  and  ejected  at  a 
velocity  approximately  equal  to  the  tangential  velocity  of  the  flywheel.  Due  to  the  inertial 
mismatch  of  the  flywheel  and  the  ball,  the  system  is  only  marginally  decelerated  during 
the  process.  Also,  a  relatively  low-powered  motor  drives  pitching  machines.  A  follow-on 
pitch  is  immediately  achievable  as  the  flywheel  is  continuously  spinning,  and  there  is  not 
an  impact  as  a  result  of  the  launch.  Going  forward  with  this  concept,  several  iterations  were 
developed  that  eventually  led  to  the  chosen  design  approach. 

This  marked  an  important  transition  from  concepts  using  observed  power-generation  char¬ 
acteristics  like  bungee  and  pneumatic  to  an  electromechanical  system.  Recall  from  Chapter 
III  that  market  analysis  did  not  reveal  any  existing  systems  that  use  an  electric  motor  as  the 
power  generation  method.  There  were  risks  associated  with  developing  an  untested  method, 
but  the  uniqueness  of  the  swarming  scenario  mandated  a  departure  from  established  prac¬ 
tices.  These  risks  will  be  discussed  in  greater  detail  in  Chapter  5. 


The  first  concept  was  essentially  a  lengthened  pitching  machine  redesigned  for  UAVs.  The 
concept  features  two  drive  pulleys,  each  powered  by  an  electric  motor.  Along  the  length 
of  the  assembly,  spring-tensioned  idler  pulleys  maintain  proper  grip  on  the  UAV  for  the 
launch.  This  concept  is  shown  in  Figure  4.5.  Note  that  the  graphical  depiction  is  for 
representation  only  and  is  not  to  scale. 
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Figure  4.5:  Side  View  of  Pitching  Machine  Concept 


Envisioned  operation  would  be  similar  to  that  of  a  baseball-pitching  machine.  Power  would 
be  applied  to  the  drive  motors,  thereby  accelerating  the  conveyor  belts  to  desired  velocity. 


58 


At  this  point,  the  UAV  would  be  inserted  into  the  system,  accelerated,  and  ejected  from  the 
far  end.  The  compression  of  the  belts  would  provide  adequate  holding  power  for  the  UAV 
without  the  need  for  a  cradle  assembly. 

While  the  stakeholders  approved  of  the  general  concept,  there  was  concern  expressed  that 
Zephyr  II  UAVs  may  not  withstand  the  instant  acceleration  force  generated  by  the  system. 
The  Zephyr  II  wing  is  constructed  from  foam  with  a  shrink-wrap  type  of  film  covering  for 
protection.  The  grip  between  the  conveyor  belts  and  the  film  would  likely  rip  the  covering 
upon  insertion  of  the  UAV.  To  mitigate  this,  a  progressive  velocity  concept  of  the  same 
principle  was  created.  This  system  is  shown  in  Figure  4.6. 


Idler  Tension  Pulleys 


Figure  4.6:  Side  View  of  Progressive  Pitching  Machine  Concept 


Envisioned  operation  for  this  system  is  similar  to  the  original  pitching  machine  concept. 
The  difference  between  the  two  is  that  the  conveyor  is  set  up  in  multiple  stages  for  pro¬ 
gressively  higher  velocities.  This  would  mitigate  the  initial  shock  as  the  UAV  accelerates 
in  stages  through  the  launching  section. 

Although  the  concept  was  generally  favored  as  a  viable  possibility  for  meeting  design  re¬ 
quirements,  the  stakeholders  did  not  approve  of  the  necessity  for  six  independent  drive 
motors.  At  best,  the  upper  and  lower  drive  pulleys  of  each  section  could  be  linked  to  one 
motor,  but  that  still  required  three  motors.  The  complexity  and  power  requirements  for  this 
concept  required  further  refinement. 

In  an  effort  to  simplify  the  staged  pitching-machine  concept,  consideration  was  given  to 
removing  the  upper  conveyor  assemblies  and  replacing  them  with  a  fixed  hold-down.  This 
is  shown  in  Figure  4.7. 

Operational  concept  is  the  same  for  the  staged  pitching  machine,  but  it  is  a  simpler  design 
mechanically.  The  upper  hold  down  is  fixed  at  the  loading  end,  and  would  be  constructed 
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Figure  4.7:  Side  View  of  Simplified  Progressive  Pitching  Machine  Concept 


out  of  a  low-friction,  flexible  material.  The  intent  was  for  the  hold-down  to  provide  ade¬ 
quate  downward  force  but  still  allow  for  UAV  passage.  Even  though  the  sytem  was  simpli¬ 
fied,  the  stakeholders  were  still  leery  of  using  three  motors.  However,  this  concept  is  what 
opened  the  discussion  that  ultimately  led  to  the  selected  design. 


4.2  Design  Selection 

Until  this  stage  of  concept  development,  consideration  had  not  been  given  to  exploring  the 
possibility  of  an  electric  motor  starting  from  rest  and  accelerating  the  UAV.  Along  this  line 
of  thought,  the  concept  shown  in  Figure  4.8  was  developed. 


The  operational  concept  for  this  design  was  to  load  the  UAV  with  no  power  applied  to 
the  drive  motor.  Once  loaded,  power  would  be  provided,  and  the  motor  would  accelerate 
the  aircraft  to  flying  velocity  from  rest.  After  the  UAV  departed  the  launcher,  the  motor 
would  be  shut  off  and  the  conveyor  would  decelerate  back  to  rest.  The  process  would  then 
be  repeated  for  follow-on  launches.  Stakeholders  were  optimistic  of  the  concept,  and  the 
decision  was  made  to  further  explore  the  design. 

The  system  was  initially  envisioned  to  utilize  a  high-grip  conveyor  belt  as  the  power- 
transfer  method.  However,  market  research  showed  that  commercially  available  conveyor 
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belts  are  not  designed  for  high-speed  operation  or  shock  loads. 

The  next  method  considered  was  the  use  of  a  timing  belt.  These  are  commonly  found 
in  automobile  applications  to  transfer  power  from  the  motor  to  various  accessories.  The 
environment  is  both  high-speed,  and  subject  to  shock-loading  due  to  rapid  changes  in  the 
motor’s  power  output.  Also,  timing  belts  have  a  high  strength-to-weight  ratio,  making  them 
ideal  for  this  application.  Unfortunately,  the  timing  belt  idea  fell  short  when  requests  for 
information  from  various  manufacturers  went  unanswered.  It  was  unknown  if  the  use  case 
presented  a  liability  concern,  or  if  they  were  unable  to  supply  a  belt  that  met  requested 
specifications.  This  led  to  the  exploration  of  using  roller  chain  as  the  power  transmission 
device. 

Roller  chain  was  originally  discarded  due  to  its  relatively  high  weight  compared  to  belts. 
However,  the  use  of  it  opened  up  a  new  concept  for  the  UAV  attachment  method.  Rather 
than  use  an  upper  hold-down  to  generate  friction  between  the  belt  and  UAV,  it  was  thought 
a  3-D  printed  interface  could  be  designed  that  would  slide  onto  the  UAV’s  existing  hook 
and  snap  into  the  chain.  The  concept  was  for  the  component  to  vertically  snap  in  place 
between  the  links  of  the  roller  chain.  This  aspect  of  the  system  will  be  discussed  in  detail 
in  Chapter  5.  It  was  mentioned  here  because  the  newfound  simplicity  afforded  by  this 
method  was  a  determining  factor  for  continuing  development. 

For  an  initial  look  at  a  potential  layout  for  this  concept,  a  baseline  CAD  model  was  devel¬ 
oped.  This  is  shown  in  Figure  4.9. 
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The  system  features  a  single  electric  motor  at  the  departure  end  of  the  launching  section. 
On  the  upper  surface,  a  low-friction  guide  is  attached  to  the  frame  to  support  the  roller 
chain.  The  return  section,  or  lower  surface,  uses  a  series  of  idler  sprockets  to  guide  the 
chain.  Tensioners  are  mounted  to  each  end  of  the  assembly  for  adjustment  of  the  chain 
tension. 

The  primary  concern  with  this  concept  was  the  availability  of  a  motor  that  could  perform 
the  task.  It  was  reasoned  that,  if  an  acceptable  motor  could  be  sourced,  the  system  had 
the  potential  to  meet  all  stakeholder  requirements  and  remain  within  the  aforementioned 
construction  and  design  limitations.  The  key  strengths  of  the  concept  are: 

1.  The  system  is  relatively  simple  from  a  mechanical  viewpoint. 

2.  The  use  of  an  electric  motor  eliminates  the  need  for  extensive  support  equipment 
required  for  pneumatic  systems. 

3.  It  was  predicted  the  system  would  meet  Requirements  1-9  for  high-level  functional¬ 
ity. 

4.  There  is  not  be  an  impact  at  launch.  The  energy  generated  during  launch  is  dissipated 
smoothly  over  time  as  the  chain  decelerates. 
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CHAPTER  5: 
Proof-of- Concept 


Referring  again  to  the  systems  engineering  (SE)  process  shown  in  Figure  6.1,  the  devel¬ 
opment  effort  was  now  at  the  bottom  point  of  the  V.  This  chapter  outlines  the  activities 
associated  with  maturing  a  concept  into  a  testable  prototype. 
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Figure  5.1:  DOD  SE  Process  Overview,  from  [19] 

To  further  explore  the  feasibility  of  the  chosen  concept,  a  proof-of-concept  (POC)  needed 
to  be  designed  and  built  to  study  the  system  characteristics  and  conduct  developmental  test 
and  evaluation  (DT&E).  The  purpose  of  DT&E  activities  are  to  support  [19]: 


•  Identify,  assess,  and  mitigate  the  technical  risks. 

•  Assess  the  technical  performance  and  system  maturity. 

•  Provide  empirical  data  to  validate  models  and  simulations. 


All  of  these  points  are  addressed  during  POC  development  as  part  of  the  design  review. 
However,  the  first  two  require  a  front-end  discussion  of  the  approach  methodology. 
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5.1  Risk  Management 


Risk  identification,  risk  assessment,  and  risk  mitigation  are  arguably  the  most  difficult  as¬ 
pects  of  a  development  effort  to  accurately  characterize.  Identifying  risk  is  challenging 
because  it  is  a  forward-looking  statement.  It  is  a  prediction  used  to  identify  perceived  is¬ 
sues  that  may  occur  in  the  future.  Predictions  inherently  imply  that  some  form  of  data  exist 
to  suggest  an  outcome.  At  the  early  phases  of  development,  there  are  frequently  “unknown 
unknowns,”  where  no  data  exist  to  alert  the  design  team  of  a  potential  issue.  To  clarify,  an 
issue  is  something  that  has  already  occurred  and  must  be  rectified.  The  purpose  of  identi¬ 
fying,  assessing,  and  mitigating  risk  is  to  prevent  issues.  The  essential  information  that  risk 
management  provides  is: 

If  This  (Identification)  This  is  the  process  of  identifying  what  future  issues  may  occur. 

For  example:  If  the  motor  seizes  during  a  launch  cycle,  then  something  will  happen. 
Then  That  (Assessment)  This  is  the  result  of  analyzing  what  would  occur  should  the  iden¬ 
tified  event  take  place.  For  example:  If  the  motor  seizes  during  a  launch  cycle,  then 
the  unmanned  aerial  vehicle  (UAV)  will  fail  to  launch. 

Do  This  (Mitigate)  Risk  mitigation  addresses  what  actions  will  be  taken  to  reduce  the 
likelihood  of  occurrence  or  severity  of  the  outcome.  For  example:  The  UAV  method 
of  attachment  will  be  designed  in  a  way  that  motor  seizure  during  launch  will  not 
cause  physical  damage  to  the  aircraft. 

The  accepted  DOD  approach  for  portraying  risk  information  is  to  use  a  risk  matrix  like  the 
one  shown  in  Figure  5.2.  The  vertical  axis  portrays  the  likelihood  of  occurrence  based  on 
percentages.  The  horizontal  axis  represents  the  severity  of  the  consequence  should  the  risk 
event  occur. 

There  are  three  primary  types  of  risk:  Technical  Performance,  Schedule,  and  Cost  [30]. 
The  Department  of  Defense  Risk  Management  Guide  for  Acquisition  Programs  suggests 
that  acceptable  levels  of  risk  should  be  tailored  to  the  constraints  and  objectives  of  each 
program  [30].  For  this  effort,  the  primary  area  of  concern  was  technical  performance  risk. 
This  is  not  to  say  schedule  and  cost  risks  were  not  assessed  and  managed  throughout  the 
process.  Schedule,  in  particular,  is  mentioned  numerous  times  throughout  prototype  de¬ 
velopment.  However,  the  central  focus  of  this  effort  was  to  demonstrate  a  new  technical 
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Figure  5.2:  DOD  Standard  Risk  Matrix,  after  [30] 

capability.  As  previously  mentioned,  limited  human  resources  mandated  a  reduction  in 
scope  for  certain  aspects  of  the  SE  process.  The  written  guidelines  for  technical  conse¬ 
quence  definitions  are  shown  in  Table  5.1. 

Table  5.1:  Technical  Risk  Consequence  Definitions,  from  [30] 

Level  Technical  Performance 

1  Minimal  or  no  consequence  to  technical  performance 

2  Minor  reduction  in  technical  performance  or  supportability;  can  be  tol¬ 
erated  with  little  or  no  impact  on  program 

3  Moderate  reduction  in  technical  performance  or  supportability  with  lim¬ 
ited  impact  on  program  objectives 

4  Significant  degradation  in  technical  performance  or  major  shortfall  in 
supportability;  may  jeopardize  program  success 

5  Severe  degradation  in  technical  performance;  cannot  meet  KPP  or  key 
technical/supportability  threshold;  will  jeopardize  program  success 


12  3  4  6 

Minimal  Minor  Moderate  Ma|or  Severe 

Consequence 


For  determining  the  likelihood  and  consequence  of  various  technical  risks,  there  usually 
exists  a  full  team  of  individuals  assigned  specifically  to  this  task.  Team  collaboration  helps 
to  mitigate  the  subjective  nature  of  this  effort.  In  this  case,  the  stakeholders  were  used  for 
this  purpose. 
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Various  methods  were  used  to  mitigate  and  manage  risk,  and  these  will  be  discussed 
throughout  the  development,  but  the  ultimate  remedy  is  knowledge.  As  subsystems  are 
developed  and  tested,  previously  unknown  information  about  the  system  is  gained.  Defini¬ 
tively  knowing  how  a  system  will  respond  in  all  scenarios  is  the  elimination  of  all  risk. 
This,  however,  is  not  possible  and  can  never  be  fully  realized.  Rather,  the  effort  is  to  un¬ 
derstand  as  much  as  is  feasible,  and  apply  that  knowledge  at  each  phase  going  forward. 
The  purpose  of  iterative  prototyping  is  to  allow  for  progressive  design  modifications,  as 
risk  is  understood.  The  objective  is  to  identify  and  mitigate  the  risks  that  fell  under  a  red 
classification  first  as  identified  in  Figure  5.3,  as  these  posed  the  greatest  threat  to  success. 
At  completion  of  the  research,  the  goal  was  for  all  technical  risks  to  fall  under  a  green 
classification. 


At  the  onset  of  POC  development,  there  were  two  primary  risks  to  be  addressed.  First,  the 
power  required  was  unknown  -  which  brought  into  question  the  availability  of  a  motor  that 
could  meet  specifications.  Second,  it  was  unknown  if  the  roller-chain  could  be  properly 
supported  in  a  manner  that  still  allowed  for  UAV  attachment.  These  risks  were  assigned  as 
shown  in  Figure  5.3. 


If  If  roller  chain  can  not 
be  properly  supported  in 
such  a  way  to  allow  for 
UAV  attachment 

Then  Launcher  is 
unable  10  interface  with 
UAVs 

Mitigation:  Conduct 
early  testing  of  this 
design  element  with 
minimal  Investment 


If  If  a  motor  can  not  be 
sourced  that  meets 
performance 

specifications-. 

Then:  Launcher  is 
unable  to  provide 
necessary  launching 
forcB- 


Mitlgation  Test  low-cost 
motor  options  to 
characterize  the  power 
required. 


Figure  5.3:  H igh-Priority  Design  Risks,  after  [30] 
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5.2  Technical  Performance  and  System  Maturity 

Technical  Readiness  Level  (TRL)  assessment  is  the  standard  metric  used  by  DOD  pro¬ 
grams  to  characterize  the  technical  maturity  of  a  system  [19].  The  nine  TRL  levels  and 
accompanying  definitions  are  show  in  Table  5.2.  The  goal  was  to  reach  TRL  7.  TRLs 
define  the  system  maturity;  while  performance  is  measured  against  requirement  thresholds 
and  objectives.  This  process  is  how  systems  are  verified  and  validated  to  ensure  they  are 
meeting  performance  specifications,  while  also  satisfying  the  operational  goals. 
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if  it  meets  design  specifications.  resolve  problems  before  finalizing  the  design? 

Actual  system  proven  through  sue-  Actual  application  of  the  technology  in  its  final  form  and  under  mis-  Operational  Test  and  Evaluation  reports, 
cessful  mission  operations.  sion  conditions,  such  as  those  encountered  in  operational  test  and  eval¬ 

uation.  Examples  include  using  the  system  under  operational  mission 
conditions. 


The  research  completed  thus  far  in  the  study  satisfies  the  requirements  for  TRL  1.  As  the 
POC  is  developed,  the  intermediate  goal  is  to  accomplish  a  TRL  of  5  prior  to  building  the 
follow-on  prototype. 


5.3  Proof-of-Concept  1 

The  final  prototype  is  the  result  of  over  100  individual  component  iterations.  As  is  common 
with  integrated  systems,  the  alteration  of  one  subsystem  usually  results  in  the  modification 
of  many  others  to  satisfy  interactions  within  the  system.  If  presented  outside  the  context  of 
the  integrated  system,  the  evolutions  of  a  single  component  are  difficult  to  convey  without 
confusion.  To  alleviate  this,  the  final  iteration  of  each  concept  is  presented  first,  followed  by 
the  chronological  component  evolution  that  led  to  the  end  product.  For  tracking  purposes, 
significant  changes  to  the  system  are  referred  to  as  numbered  versions.  The  POC  is  broken 
into  four  versions,  POC-1  through  POC-4. 

The  reader  will  note  multiple,  future  references  to  a  “prototype.”  To  avoid  confusion, 
the  proofs-of-concept  were  wood-framed  mockups  used  as  stepping-stones  to  later  de¬ 
velop  a  usable,  long-term  prototype.  The  POCs  were  never  intended  for  long-term  use 
by  ARSENL.  On  that  note,  most  of  the  discussed  design  decisions  and  calculations  were 
driven  towards  the  eventual  prototype  development,  not  the  POC. 

5.3.1  Overview 

An  overview  of  POC-1  is  shown  in  Figure  5.4.  Note  that  fasteners,  the  roller  chain,  and 
power  transfer  belts  were  not  modeled  in  the  computer-aided  design  (CAD).  The  proto¬ 
type’s  frame  was  constructed  out  of  readily  available  2X4  pine  lumber.  Functionally, 
it  operated  in  a  similar  fashion  to  the  final  concept  discussed  in  Chapter  4. 

The  rear  and  front  sides  feature  a  six-inch  diameter,  quick-disconnect  sprocket  sized  for 
ANSI  40  roller  chain.  The  sprocket  is  supported  by  a  one-inch,  steel  drive  shaft,  mounted 
on  split-case,  pillow-block  bearings.  Bearings  are  attached  to  adjustable,  stainless  steel 
conveyer-belt  tensioners  that  are  through-bolted  to  the  wood  frame.  Two  PVC  pipes  run 
the  length  of  the  launcher  as  support  rails  for  the  UAV. 

For  clarity,  a  close  view  of  the  front  side  is  shown  in  Figure  5.5.  For  POC-1,  a  small 
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Roller  Chain  Guide 


PVC  Support  Rail 


Figure  5.4:  POC-1  Overview 


Main  Drive  Motor 


Figure  5.5:  POC-1  Front  Detail 


motor  typically  used  in  remote  control  aircraft  applications  is  mounted  with  a  gearing  ratio 
of  60:9.  Power  transfer  from  the  motor  to  the  driving  sprocket  is  accomplished  with  a 
miniature  timing  belt  (not  shown  in  the  CAD). 

UAV  attachment  is  accomplished  via  a  3-D  printed  interface.  A  front-quarter  view  of  this 
component  is  shown  in  Figure  5.6.  The  piece  is  removable  from  the  UAV  for  legacy 
launcher  compatibility,  satisfying  Requirement  6  (R6).  The  component  slides  onto  the 
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Attach  Hook  (Anchored  in  UAV) 


Figure  5.6:  3-D  Printed  UAV  Interface 

UAV’s  hook  and  is  clipped  in  place  as  the  hook  passes  a  pinch  point  in  the  channel.  After 
attaching  it  to  the  aircraft,  downward  pressure  is  applied  with  the  clip  in  position  over  the 
roller  chain.  The  pegs  on  the  bottom  of  the  3-D  component  then  clip  into  the  roller  chain 
for  UAV  attachment.  It  requires  approximately  five  pounds  of  vertical  force  to  insert  or  re¬ 
lease  the  interface  from  the  chain.  The  method  of  release  concept  for  this  component  is  for 
the  teeth  of  the  front  drive  sprocket  to  automatically  eject  the  interface,  thereby  detaching 
the  UAV  from  the  chain. 

5.3.2  Roller  Chain  and  UAV  Interface  Design 

To  comply  with  the  previously  discussed  risk  mitigation  plan,  the  first  components  of  in¬ 
terest  were  the  roller  chain  and  the  UAV  interface.  These  were  not  trivial  design  tasks. 
Commencing  with  the  roller  chain,  extensive  research  was  required  to  design  the  system. 

To  give  the  reader  an  accurate  perspective  of  the  complexity  of  this  task,  a  single  man¬ 
ufacturer,  Rexnord,  produces  5,000  variants  of  roller  chain  solutions  [32].  To  limit  the 
sizing  options,  it  was  decided  to  work  with  the  standard  American  National  Standards  In¬ 
stitute  (ANSI)  chain  sizes  available  in  the  United  States.  This  scale  ranges  from  ANSI 
25  to  ANSI  240.  The  ultimate  tensile  strength  of  these  chains  is  780  and  112,500  pounds 
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respectively  [33].  For  reference,  ANSI  35  chain  is  approximately  the  size  used  for  most 
bicycles.  Rexnord’s  chain  guide  provided  information  that  showed  chain  sizing  and  RPM 
of  the  drive  sprocket  are  directly  related.  Smaller  chains  are  better  suited  for  higher  RPMs 
(the  dependence  of  this  measurement  on  RPM  also  affected  the  sprocket  sizing,  discussed 
later)  [32].  If  load  requirements  dictated  higher  tensile  strength  than  the  appropriate  chain 
size  could  provide,  chains  may  be  constructed  in  parallel  strands  (attached  side-by-side). 

Requirement  18  (R18),  dictate  no  more  than  20  pounds  of  force  be  applied  to  the  UAV 
hook.  On  the  five  pound  UAV,  this  translates  to  a  4g  acceleration  limit.  The  working  load 
(less  than  the  ultimate  tensile  strength)  for  ANSI  25  chain  is  140  pounds  [33].  So,  assuming 
friction  and  tension  loading  are  minimal,  even  the  smallest  chain  provides  a  safety  factor 
of  7.0.  The  goal  was  to  use  the  smallest,  technically  acceptable  solution.  However,  the 
dimensions  of  this  chain  were  so  small  that  it  was  reasoned  a  UAV  interface  would  not  be 
able  to  clip  with  enough  holding  force  to  launch  the  aircraft.  It  was  decided  that  one  size  up 
from  ANSI  25  should  suffice;  therefore,  a  three-foot  section  of  ANSI  35  chain  was  ordered 
with  an  idler  sprocket  for  testing.  An  idler  sprocket  is  a  smaller,  free- spinning,  sprocket 
used  for  chain  alignment  and  support. 

Having  selected  a  size  for  the  chain,  the  UAV  interface  was  designed.  The  on-hand  avail¬ 
ability  of  3-D  printing  made  it  a  relatively  straightforward  task.  The  goal  was  to  make  a 
basic  prototype  into  which  the  UAV’s  hook  could  slide  with  attachment  prongs  sized  for 
the  chain.  Two  images  of  the  CAD,  one  sectioned  for  clarity,  are  shown  in  Figure  5.7  and 
Figure  5.8. 

The  tests  consisted  of  two  parts.  The  first  was  to  see  if  tolerances  were  accurate  for  the 
hook  sliding  into  the  interface.  These  were  found  to  be  too  tight,  and  were  adjusted  in 
follow-on  versions.  The  second  set  of  tests  was  to  observe  how  the  interface  interacted 
with  the  chain.  The  tests  performed  and  qualities  examined  were: 

•  A  snap-in  test  was  performed  to  determine  if  tactile  or  audible  feedback  were  present 
to  indicate  the  clip  was  secure  in  the  chain. 

•  A  pull-off  test  followed  to  observe  the  force  required  to  remove  the  clip  from  the 
chain. 

•  The  chain,  with  clip  attached,  was  then  pulled  over  the  sprocket  to  determine  if  the 
teeth  would  eject  the  interface. 
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Figure  5.7:  CAD  of  First  UAV  Interface 


Figure  5.8:  CAD  of  First  UAV  Interface 
(Sectioned) 


These  tests  revealed  that  ANSI  35  chain  was  also  too  small.  The  snap-in  functionality  of  the 
interface  did  not  work  well  with  the  chain.  The  issue  was  a  balance  of  how  much  material 
could  be  removed  from  the  pegs  that  inserted  into  the  chain.  This  concept  is  illustrated  in 
Figure  5.9. 


Figure  5.9:  Expanded  UAV  Interface 

The  width  of  the  gap  determines  how  much  flex  the  pegs  have  when  being  inserted  into  the 
chain.  The  problem  with  ANSI  35  chain  is  that,  when  the  correct  amount  of  material  is 
removed  from  the  clip  to  insert  properly,  there  is  not  enough  holding  material  remaining. 
On  a  positive  note,  testing  revealed  the  kick-out  functionality  using  a  sprocket  appeared  to 
work  well.  As  a  result  of  this  testing,  the  decision  was  made  to  increase  the  size  of  chain 
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to  ANSI  40.  For  brevity,  further  mention  of  the  chain  sizing  is  reduced  to  include  only  the 
series  number. 

Standard  40-series  roller  chain  has  a  working  load  of  810  pounds  with  a  weight  of  approx¬ 
imately  0.4  pounds  per  foot  [33].  The  maximum  allowable  drive  sprocket  RPM  for  this 
series  is  8,000  with  a  normal  limit  of  6,000  [32].  These  specifications  were  well  within 
the  limits  of  the  design,  and  they  allowed  for  considerable  flexibility  in  the  sprocket  sizing 
to  achieve  a  linear  chain  velocity  of  35  mph  (R13).  In  addition  to  meeting  performance 
requirements,  attachment  links  were  readily  available  for  40  series  chain. 

Attachments  are  a  single  link  that  can  be  inserted  into  the  chain  with  plates  protruding  in 
various  configurations  for  mounting  attachments.  Should  the  UAV  interface  fail,  using 
attachments  allowed  for  a  risk  mitigation  alternative.  If  an  issue  were  to  arise,  it  was 
reasoned  the  ability  to  bolt  an  adaptor  to  the  chain  would  allow  for  enough  flexibility  in 
the  interface  design  to  solve  an  issue. 


5.3.3  Sprocket  Sizing  and  Configuration 

Roller  chains  are  typically  used  in  either  power  transmission  or  conveyor  applications. 
Power  transmission  designs  are  intended  for  high-speed  shock  loads  with  a  short  distance 
between  sprockets.  Conveyor  applications  are  for  low-speed,  smooth  operation  over  long 
distances.  This  became  the  first  concern  with  designing  the  drive  -  the  launcher  required  a 
hybrid  of  both.  It  is  high-speed  with  shock  loading  but  has  a  long  distance  between  drive 
sprockets. 

The  manufacturer-recommended  support  structure  for  high-speed  rolling  chain  is  to  have 
a  maximum  distance  between  shafts  of  20  times  the  pitch  of  the  chain  [34].  This  was  to 
control  resonance  in  the  chain  and  prolong  its  useful  life.  For  40-series  chain,  the  pitch 
distance  is  0.50  inches  [32].  This  requires  that  idler  sprockets  be  placed  every  10  inches 
along  the  return  side  of  the  span.  The  return,  or  slack,  side  refers  to  the  bottom  of  a 
horizontally  configured  roller  chain  assembly.  To  satisfy  this  requirement,  an  over/under 
idler  configuration  was  implemented.  This  configuration,  shown  in  Figure  5.10,  uses  an 
alternating  high-to-low  chain  path  around  the  sprockets.  The  light  grey  line  indicates  the 
chain  path. 
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Figure  5.10:  Fligh-to-Low  Configuration  of  Idler  Sprockets 

Upon  review,  the  stakeholders  were  concerned  about  the  friction  and  total  system  inertia 
the  idler  sprockets  would  add.  Configurations  that  are  outside  of  the  manufacturer’s  recom¬ 
mendations  will  typically  result  in  reduced  life  of  the  chain.  However,  roller  chains  have 
substantial  service  lives;  therefore,  the  decision  was  made  to  reduce  the  number  of  idler 
sprockets.  For  this  POC,  only  two  idler  sprockets  were  ordered.  The  intent  was  to  ob¬ 
serve  system  characteristics  and,  if  more  were  necessary,  they  would  be  added  in  follow-on 
iterations. 

For  supporting  the  upper  section  of  chain,  a  low-friction  guide  is  used.  These  are  precision 
machined  out  of  ultra-high-molecular-weight  polyethylene  (UHMW)  material  to  match  the 
roller  chain’s  profile.  The  necessity  for  a  straight,  consistently-supported  path  along  which 
the  UAV  would  launch  eliminated  all  other  options. 

Sizing  the  main  sprockets  was  a  function  of  minimum  tooth  engagement,  and  desired  linear 
velocity  of  the  chain.  Typically,  the  drive  sprocket  (connected  to  the  power  source),  and 
the  driven  sprocket  are  different  diameters.  There  are  ratio  limitations  established  for  this 
scenario,  but  the  POC  design  allowed  for  both  to  be  the  same  diameter.  Given  the  elimina¬ 
tion  of  this  factor,  the  minimum  tooth  engagement  rules  were  then  considered.  Rexnord’s 
design  guide  recommends  using  sprockets  with  a  minimum  of  21  teeth  for  applications 
up  to  15  m/s  (33.6  mph)  [32].  It  also  points  out  that  larger  diameter  sprockets  are  better 
in  all  respects  because  they  significantly  reduce  the  polygon  effect  [32].  This  effect  will 
not  be  discussed  in  detail,  but  it  causes  resonance  from  a  velocity  imbalance  in  the  chain. 
For  reference,  a  30-tooth  sprocket  has  eight- times  more  efficient  than  that  of  an  11 -tooth 
sprocket  [33].  Having  determined  a  minimum  size  of  21  teeth  (approximately  3.5  inches  in 
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diameter),  and  established  that  larger  diameters  are  more  efficient,  an  upper  limit  needed  to 
be  found. 

The  Rexnord  guide  suggested  that  any  sprocket  from  26  to  40  teeth  is  the  most  appropriate 
choice  for  highly-stressed,  high-revolution  applications  [32].  At  this  size  range,  the  “poly¬ 
gon  effect  is  negligible,”  and  “vibration  and  noise  features  meet  the  highest  demands”  [32]. 
Sprockets  above  45  teeth  have  reduced  take-up  capacity  which  means  chains  must  be  re¬ 
placed  at  higher  intervals  [32].  To  determine  what  size  should  be  used  between  26  and  45 
teeth,  the  motor  source  needed  to  be  considered. 

It  was  still  unknown  what  type  of  motor  would  be  selected  for  the  system.  Alternating- 
current  (AC)  motors  were  still  a  viable  option.  These  motors  are  designed  to  operate  at 
maximum,  fixed  RPM  of  1800  and  3600.  Direct-current  (DC)  motors  operate  at  any  RPM 
as  a  function  of  supplied  voltage;  therefore,  the  limiting  consideration  for  sprocket  size  was 
the  use  of  an  AC  motor.  If  a  direct-drive  configuration  were  used  1800  RPM  would  be  the 
drive  sprocket  RPM,  with  some  reduction  for  load.  If  gearing  reduction  were  used,  a  3600- 
RPM  motor  would  be  chosen  and  geared  appropriately.  To  satisfy  all  possible  options, 
the  drive  sprocket  was  sized  to  work  with  a  direct-drive,  1800-RPM  motor.  A  6.54-inch 
sprocket  at  1800  RPM  produces  a  linear  chain  velocity  of  35  mph.  This  was  the  intended 
size  to  be  used  in  the  prototype,  but  an  error  in  the  order  resulted  in  a  36  tooth,  6.02-inch 
sprocket  being  delivered.  The  plan  was  to  correct  the  size  in  follow-on  iterations.  For  now, 
this  was  considered  acceptable  for  a  POC. 

Finally,  a  method  needed  to  be  conceived  to  adjust  the  chain  tension.  Chains  will  elongate 
over  time,  and  tension  greatly  affects  the  performance  of  the  drive.  If  it  is  too  tight,  and 
excess  friction  causes  early  wear  and  excessive  power  draw.  If  tension  is  too  loose,  and 
chain  resonance  causes  early  wear  and  introduces  the  potential  for  derailment.  The  slack 
present  in  the  return  section  measures  proper  tension.  Guidelines  dictate  this  value  be  equal 
to  four  percent  of  the  free-span  [34].  To  adjust  the  tension,  conveyer-belt  tensioners  shown 
in  Figure  5.11  were  used. 

These  tensioners  have  three  inches  of  adjustable  travel.  They  also  have  an  elongated  bolt 
pattern  that  allows  for  vertical  adjustment  in  the  location  of  the  pillow-block  bearings. 
Combined  with  left/right  positioning  of  the  sprocket  on  the  shaft,  virtually  unlimited  ad- 
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Figure  5.11:  Conveyor-Belt  Tensioner 


justment  of  sprocket  alignment  is  possible.  A  graphical  depiction  of  the  degrees  of  freedom 
is  shown  in  Figure  5.12. 


Figure  5.12:  Tensioner  Degrees  of  Freedom 


From  the  perspective  of  a  designer,  this  added  welcomed  flexibility.  From  the  perspective 
of  the  user,  this  added  undesired  complexity.  Given  the  importance  of  sprocket  alignment, 
and  the  knowledge  that  a  wood  frame  would  not  be  square,  the  design  team  went  forward 
with  the  tensioner  selection.  It  will  later  be  shown  that  both  parties  were  correct.  These 
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components  were  needed  for  the  early  prototypes,  but  adjustment  was  constant  and  not 
practical  for  the  end-user. 


5.3.4  Motor  Selection 

It  was  known  at  the  time  of  construction  that  the  motor  chosen  for  POC-1  was  undersized. 
However,  Advanced  Robotic  Systems  Engineering  Laboratory  (ARSENL)  had  dozens  of 
the  motors  on  hand,  it  presented  a  cost-effective  way  to  observe  basic  motion  of  the  system. 
The  goal  was  for  it  to  provide  enough  power  to  slowly  accelerate  the  system  to  whatever 
velocity  it  could  manage.  Knowing  it  had  marginal  torque  for  the  task,  it  was  geared  at  60:9 
using  pulleys  and  a  miniature-series  timing  belt.  The  setup  is  shown  in  Figure  5.13.  Initial 
tolerance  issues  with  the  drive  shafts  delayed  their  installation;  therefore,  wood  dowels 
were  temporarily  substituted. 


Figure  5.13:  Motor  and  Gearing  Setup 


Mathematical  models  of  the  system  had  not  been  calculated,  which  resulted  in  a  gross  un¬ 
derestimate  of  the  torque  required.  The  motor  stalled  immediately  upon  power  application 
and  was  completely  unusable.  The  reason  a  mathematical  model  had  not  been  created  is 
discussed  during  the  discussion  of  POC-2  (Section  5.4). 
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5.3.5  Structure 

Mobility  of  the  system  was  not  a  concern  for  this  iteration.  The  only  goal  of  POC-1  was  to 
verify  the  sprocket  layouts  and  the  UAV  interface.  With  this  in  mind,  a  simple  saw-horse 
design  shown  in  Figure  5.14  was  constructed.  The  length  was  chosen  at  eight  feet  based  on 
the  available  size  of  on-hand  materials.  The  center  section  consists  of  two  2X4s  laminated 
together  with  relief  cuts  at  either  end  to  clear  the  main  sprockets.  Four  2X4s  are  used 
to  mount  the  PVC  support  rails.  These  are  shown  horizontally  protruding  from  each  side 
of  the  center  section.  Drop-down  mounts  used  to  secure  the  idler  sprockets  are  attached 
at  equal  distances  from  either  end.  The  launch  angle  was  designed  to  match  ARSENL’s 
current  launcher  at  seven  degrees  of  incline. 


Figure  5.14:  POC-1  Frame 


The  shaft  diameter  for  the  main  sprockets  was  chosen  at  one  inch.  This  is  the  largest 
available  diameter  for  which  finish-bore  sprockets  can  be  ordered,  and  rigidity  was  favored 
over  the  marginal  weight  savings  of  a  smaller  shaft.  Also,  high  torque  would  be  transmitted 
via  the  shaft;  hence  keyed  shafts  were  selected  to  absorb  the  energy.  Keyed  shafts  have  a 
machined  relief  to  insert  square  stock  between  the  shaft  and  sprocket.  This  is  to  ensure  that 
there  is  no  rotational  slippage.  The  concept  is  shown  in  Figure  5.15. 

The  main  bearings  selected  were  inexpensive,  split-case  bearings  that  utilize  a  pillow-block 
for  mounting.  They  are  rated  for  the  desired  RPM  and  load,  and  allow  for  a  few  degrees 
of  shaft  misalignment  to  permit  tensioner  adjustment.  Perfectly  rigid  bearings  would  have 
required  both  tensioners  to  be  adjusted  simultaneously  to  avoid  binding. 

When  initial  assembly  of  the  bearings  and  shaft  was  attempted,  the  shaft  was  too  large  to 
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Figure  5.15:  Keyed  Shaft 


fit.  Efforts  were  made  to  freeze  the  shaft  while  heating  the  bearing,  but  this  also  failed. 
Tolerances  for  both  were  correct  during  the  ordering  process,  but  it  was  discovered  that  the 
process  of  machining  the  key  relief  could  sometimes  compress  the  component  out  of  true 
round.  A  replacement  order  was  placed  for  certified  shafts  with  tighter  tolerances,  and  the 
issue  was  eliminated. 


5.3.6  Findings  and  Recommendations 

From  the  perspective  of  reducing  the  motor  availability  risk,  POC-1  was  unable  to  offer 
any  insight  due  to  the  undersized  motor.  However,  moving  the  chain  assembly  by  hand  did 
confirm  the  UAV  interface  was  ejecting  as  desired.  Also,  the  following  engineering  lessons 
were  learned  and  applied  going  forward: 

Roller  Chain  and  UAV  Interface 

•  It  appeared  that  ANSI  40  roller  chain  was  an  appropriate  size  for  the  UAV 
interface.  The  increased  pitch  from  ANSI  35  allowed  for  more  support  material 
in  the  peg,  while  still  providing  a  favorable  clipping  action  when  inserted  into 
the  chain. 

•  The  stakeholders  were  pleased  with  the  concept  designed  for  the  UAV  interface. 
However,  the  request  was  made  to  reduce  the  volume  and  streamline  the  com¬ 
ponent.  3-D  printed  parts  are  priced  by  volume;  hence  a  reduction  in  volume 
is  also  a  cost-savings.  Additionally,  the  time  required  to  print  the  component  is 
reduced.  Streamlining  the  part  was  an  aerodynamic  consideration  because  the 
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interface  remains  attached  to  the  UAV  during  flight. 

Sprocket  Sizing  and  Configuration 

•  The  six-inch  main  sprockets  were  ordered  with  a  quick-disconnect  hub.  This 
is  a  two-part  design  where  the  hub  and  sprocket  are  bolted  together.  From 
a  cost  perspective,  the  hub  is  inexpensive  compared  to  the  sprocket.  If  the 
shaft  diameter  changed  in  follow-on  prototypes,  replacing  the  hub  would  be 
lower  cost  than  ordering  a  new  sprocket.  While  the  reasoning  was  sound,  the 
application  was  not  ideal.  These  hubs  are  mated  to  a  sprocket  using  a  tapered 
compression  fit.  To  correctly  seat  this  type  of  mate,  the  fastening  screws  must 
be  methodically  tightened  to  precise  torques.  It  was  a  cumbersome  process  and 
was  later  removed  from  the  design. 

•  Conclusions  were  not  possible  on  the  layout  of  the  sprockets  until  an  adequate 
motor  could  be  acquired  and  installed.  This  became  the  top  priority  for  POC-2. 

•  Upon  receiving  the  tensioners,  it  was  noticed  that  there  was  a  significant  amount 
of  play  in  the  vertical  and  horizontal  axis  of  the  bracket.  This  was  probably  not 
an  issue  for  a  conveyor  belt,  but  for  the  sprocket  assembly,  it  was  unaccept¬ 
able.  Shims  were  used  to  temporarily  address  the  issue,  but  it  was  clear  a  better 
solution  would  be  needed. 

Motor  Selection 

•  It  was  thought  gearing  ratios  could  be  used  to  compensate  for  an  under-powered 
motor.  The  mechanical  theory  is  sound  from  a  mathematical  approach  where 
torque  is  inversely  proportional  to  speed.  However,  the  electro-mechanical 
physics  of  an  electric  motor  impose  an  entirely  different  set  of  limitations  that 
were  not  considered.  While  the  application  was  a  failure,  this  realization  played 
a  critical  role  in  motor  selection  for  future  prototypes. 

Structure 

•  The  structure  functioned  well  and  as  intended.  It  would  remain  unchanged  for 
POC-2. 


5.4  Proof-of-Concept  2 

The  second  version  of  the  POC  focused  on  modeling  the  system  and  selecting  a  motor 
source.  While  that  effort  was  occurring,  another  temporary  power  source  was  acquired  to 
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observe  the  roller  chain  in  motion  and  analyze  sprocket  layout.  The  new  assembly  is  shown 
in  Figure  5.16. 


Figure  5.16:  POC-2  New  Motor  Configuration 


The  team  selected  a  1/2  HP,  AC  motor  designed  to  run  at  3600  RPM.  The  on-hand,  three- 
foot  section  of  35-series  chain  was  repurposed  to  transfer  power  to  the  drive  sprocket.  The 
gearing  ratio  was  set  at  1.6:1.  This  equated  to  an  unloaded  drive  sprocket  RPM  of  2,250,  or 
40.16  MPH  linear  chain  velocities.  An  inexpensive  potentiometer  designed  for  AC  motors 
was  ordered  to  adjust  the  speed  of  the  motor. 

The  first  round  of  testing  for  this  phase  was  observational  only,  and  was  conducted  by 
applying  power  to  the  motor  and  filming  various  sections  of  the  chain  to  observe  charac¬ 
teristics.  The  dual  idler  sprocket  setup  appeared  to  work  well  with  no  noticed  issues:  no 
derailments  of  the  chain  were  observed,  and  the  resonance  on  the  return  side  was  minimal. 

The  second  round  of  testing  was  focused  on  gathering  analytic  data.  The  values  measured 
were  the  time  it  took  to  accelerate,  and  the  final  chain  velocity  achieved.  Chain  velocity 
was  determined  using  high-speed  video  playback  and  counting  the  number  of  frames  it  took 
for  a  fixed  point  in  the  chain  to  travel  one  foot.  Final  velocity  was  recorded  at  36  MPH. 
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The  time  required  to  reach  this  velocity  was  highly  subjective  and  relied  on  audible  cues 
to  determine  when  acceleration  was  complete.  This  value  was  approximately  six  seconds. 
Two  important  conclusions  were  drawn  from  this  phase  of  testing: 

1.  Using  a  linear  acceleration  assumption,  the  time  allotted  to  reach  35  mph  on  an  eight- 
foot  launcher  is  0.312  seconds.  The  motor  required  six  seconds  to  accomplish  this 
(multiple,  full  revolutions  of  the  roller  chain).  This  suggested  the  motor  was  still 
significantly  underpowered. 

2.  Even  though  it  took  far  too  long  to  reach  maximum  velocity,  the  1/2  HP  motor 
showed  a  final  velocity  decrease  of  only  10.4%  from  the  unloaded,  theoretical  value. 
This  observation,  combined  with  the  time  taken  to  accelerate,  suggested  the  dominat¬ 
ing  torque  requirement  was  due  to  acceleration  of  the  system  rather  than  steady-state 
load. 


5.4.1  System  Modeling 

The  standard  SE  approach  when  designing  a  new  system  is  to  model  first,  then  build  pro¬ 
totypes  to  validate  the  models.  The  reader  has  likely  noted  the  backward  process  outlined 
thus  far.  To  explain,  the  issue  preventing  the  correct  order  of  development  was  an  inability 
to  use  any  of  the  roller  chain  design  guides  for  this  purpose.  The  guides  are  all  based  on  the 
premise  that  a  power  source  had  already  been  selected,  and  the  chain  was  designed  to  match 
the  power  source  -  not  the  other  way  around.  After  an  exhaustive  effort  to  locate  modeling 
methods  for  chain,  the  decision  was  made  to  approximate  the  system  with  a  conveyor  belt 
instead. 

Research  conducted  during  the  concept  development  effort  uncovered  an  online  calcula¬ 
tor  used  to  characterize  the  inertia  and  torque  required  for  conveyor  belt  assemblies.  The 
source  can  be  found  at  [35].  Although  the  interactions  of  belts  and  pulleys  are  not  equiv¬ 
alent  to  roller  chains  and  sprockets,  the  motion  and  inertial  forces  present  in  the  systems 
were  thought  to  be  similar.  Following  this  approach,  Figure  5.17  shows  the  terminology 
used  for  identifying  various  inputs  needed  for  the  calculation. 

Observing  the  layout  of  Figure  5.17,  it  is  apparent  the  configuration  is  very  similar  to  POC- 
2.  A  motor  transfers  power  via  primary  and  secondary  pulleys  to  the  main  drive.  The 
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Figure  5.17:  Conveyor  Components,  from  [35] 


drive  pulley  then  pulls  a  guided  belt  to  transfer  the  load.  At  the  time  of  calculation,  it  was 
unknown  what  the  quantitative  difference  would  be  between  chain  and  a  conveyor  belt; 
however,  without  an  alternative,  this  was  the  only  viable  approach. 


The  following  walk-through  of  how  the  model  was  implemented  is  based  on  the  physical 
characteristics  of  POC-2.  Later,  the  same  process  would  be  used  to  optimize  the  length  and 
gearing  ratios  for  the  system.  Figure  5.18  displays  the  various  inputs  and  values  used  for 
the  online  calculator. 


Load  and  linear  guide 


Total  weight  of  loads  and  table 

Friction  coefficient  of  the  guide 

W 

M  - 

14.06  [lb] 

0.05 

Drive  pulley  specifications 

Drive  pulley  diameter 

D0  * 

6  M 

Drive  pulley  weight 

wD 

2  pb/pc] 

Number  of  drive  pulleys 

n  - 

2  [pc] 

Efficiency 

n 

95  [%] 

External  force 

r*  o  [ib) 

Transmission  belt  and  pulleys  or  gears 

Primary  pulley  (gear) 

Secondary  pulley  (gear) 

pitch  circle  diameter  (PCD) 

O „  - 

1 .99  [in] 

DoS  =  3.19  [in] 

weight 

W„,  , 

.5  [lb] 

=  1.6  Pbl 

Mechanism  Placement 

Mechanism  angle 

a  - 

?n 

Figure  5.18:  Calculation  Inputs,  from  [35] 

Total  weight  was  determined  by  adding  the  chain  weight  to  that  of  the  UAV.  The  friction 
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coefficient  was  estimated  for  the  linear  chain  guide.  Sprocket  efficiency  was  estimated  at 
95%  based  on  [32].  The  remaining  inputs  have  been  discussed  as  elements  of  the  design. 

Not  shown  in  Figure  5.18  were  the  additional  calculator  inputs  for  the  system  to  accelerate 
to  616  inches  per  second  (35  mph)  in  0.312  seconds.  Finally,  a  safety  factor  (or,  in  this 
case,  margin  of  error)  was  selected  at  1.5. 

Only  the  results  were  presented.  If  the  equations  are  of  interest,  input  the  values  shown  into 
the  online  calculator,  then  open  the  full  report  link.  Otherwise,  the  key  inputs  and  outputs 
are  shown  in  Table  5.3. 


Table  5.3:  POC-2  Model  Results 


Parameter 

Value 

Length  of  Launcher  (ft) 

8 

Launch  Time  (s) 

0.312 

g-loading 

5.114 

Chain  Length  (ft) 

16.8 

Chain  Weight  (lb) 

7.06 

Chain  Weight  +  Load  Weight  (lb) 

14.06 

Load  Intertia  (oz-in2) 

915.8 

Acceleration  Torque  (in-lb) 

187.8 

Load  Torque  (in-lb) 

4.75 

Total  Torque  Required  (in-lb) 

288.8 

Required  Motor  RPM 

3145 

Motor  HP 

14.41 

Motor  Power  (kW) 

10.75 

As  previously  discussed,  the  time  to  launch  was  calculated  using  1-D  kinematic  equations 
with  a  constant  acceleration  (linear  velocity  profile)  assumption,  g-loading  for  the  launch 
was  determined  from  the  change  in  velocity  over  time,  with  respect  to  the  acceleration 
of  gravity.  Chain  length  (CL)  was  estimated  by  adding  a  10%  correction  factor  to  the 
launcher  length  (L).  This  was  to  account  for  the  idler  sprockets  and  slack  in  the  return  line. 
The  equation  used  is  shown  for  clarity.  Note  that  the  drive  sprocket  radius  was  initially 
overlooked  in  the  estimate. 

CL  =  2^L  +  OIL  (5.1) 

forward  and  return  length  correction  factor 
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The  online  calculator’s  outputs  were  load  inertia,  required  torques,  and  required  motor 
RPM  [35].  A  motor’s  HP  rating  is  calculated  by  multiplying  torque  output  by  the  RPM 
of  the  motor  (a  constant  is  also  in  the  equation  to  correct  for  units).  The  most  demanding 
scenario  was  to  assume  the  motor  would  be  required  to  output  the  calculated  total  torque 
while  at  maximum  (required)  RPM.  Motor  power  expressed  in  kilowatts  is  a  direct  unit 
conversion  from  HP.  It  was  only  calculated  to  simplify  comparisons  with  motors  that  used 
this  unit  of  measurement  over  a  HP  rating. 

Recall  the  initial  length  for  POC-1,  and  therefore  POC-2,  was  selected  because  it  matched 
the  available  length  of  on-hand  materials  to  construct  the  frame.  With  a  mathematical 
model  now  available  to  characterize  the  system,  a  length  sensitivity  analysis  could  be  con¬ 
ducted  to  refine  this  value. 


5.4.2  Length  Sensitivity 

The  purpose  for  the  length  sensitivity  study  was  to  observe  the  relationship  between  accel¬ 
eration  and  load  torque  requirements.  For  a  longer  launch  section,  the  acceleration  torque 
decreases  (more  time  is  available  for  the  system  to  reach  launch  velocity),  while  the  load 
torque  increases  (chain  weight  increases  because  longer  sections  are  required). 

For  POC-2,  at  eight-feet  long,  the  calculator  showed  acceleration  and  load  torques  of  187.8 
and  4.75  inch-pounds,  respectively.  Total  torque  required  of  288.8  inch-pounds  was  the 
summation  of  these  values,  with  the  1.5  safety  factor  added.  As  predicted  from  POC-1 
testing,  the  model  showed  acceleration  torque  was  the  dominating  factor.  However,  the 
inversely  proportional  relationship  of  these  torque  requirements  means  that  there  is  an  opti¬ 
mal  length  for  the  system  where  total  the  torque  required  is  minimized.  Finding  that  length, 
with  the  hopes  it  was  within  design  limitations,  was  the  desired  outcome  for  the  study. 

At  the  onset  of  the  sensitivity  study,  two  inputs  were  changed  from  those  shown  for  POC- 
2.  The  primary  and  secondary  sprocket  diameters  were  changed  to  two  and  four  inches, 
respectively  (the  weight  estimate  remained  the  same).  This  enabled  the  development  team 
to  work  with  a  reduction  ratio  that  was  easier  to  manipulate  of  2:1  instead  of  1.6:1.  The 
analysis  was  performed  by  manually  entering  required  acceleration  times  and  chain  weights 
for  launcher  lengths  in  one-foot  increments  from  eight  to  16  feet  long.  When  it  became 
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apparent  that  the  optimal  length  was  beyond  16  feet,  the  interval  was  increased  to  20  feet. 
The  lowest  total  torque  required  occurred  somewhere  between  a  40-  and  80-foot  launcher 
length.  Since  this  was  well  outside  of  design  requirements,  a  specific  length  was  not  found. 
A  summary  of  the  results  is  shown  in  Table  5.4. 

Even  though  the  minimum  torque  point  was  not  achievable  for  this  design,  the  study 
showed  that  longer  lengths  required  less  torque.  As  a  result,  the  following  observations 
were  made: 

1.  For  the  lengths  that  satisfied  trailer  length  requirements  (shorter  than  16  feet),  longer 
solutions  required  less  power  and  exerted  lower  forces  on  the  UAV. 

2.  The  study  confirmed  load  torque  accounted  for  a  very  small  percentage  of  the  total 
torque  required.  This  was  important  because  it  suggested  variances  in  UAV  weights 
should  not  significantly  affect  end-speeds. 

3.  Launchers  shorter  than  11  feet  exerted  too  much  g  on  the  UAV’s  hook  to  satisfy  the 
20  pound  limitation  mandated  in  Requirement  18  (R18). 

The  study  narrowed  the  range  of  selection  from  12  to  16  feet  for  the  next  prototype,  but  the 
team  still  needed  justification  to  select  a  value  within  that  range.  To  initiate  the  process,  the 
16-foot  upper  limit  was  reduced  to  14.  This  was  to  accommodate  any  support  systems  that 
might  extend  beyond  the  actual  chain  drive.  For  example,  the  PVC  guide  rails  on  POC-2 
were  10  feet  long  while  the  chain  drive  was  only  eight.  The  stakeholders  requested  the 
shortest  option  (11  feet)  because  it  was  the  smallest  and  lightest  solution.  The  design  team, 
however,  was  still  concerned  about  the  model’s  accuracy,  and  reasoned  a  longer  selection 
allowed  for  more  flexibility.  If  the  motor  chosen  were  found  to  have  excess  power,  the 
length  could  easily  be  shortened.  The  same  does  not  hold  not  true  for  lengthening  the 
prototype  if  it  were  underpowered.  As  a  tradeoff  to  satisfy  both  parties,  a  mid-point  length 
of  12  feet  was  selected. 
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5.4.3  Motor  Selection 


For  a  12-foot  launcher,  the  online  calculator  showed  that  an  11.93  HP  (8.9  kW)  motor 
was  required.  The  total  torque  requirement  was  191.6  inch-pounds.  Using  these  values  to 
initiate  the  search,  the  following  observations  were  made: 

•  AC  motors  that  produce  10-12  HP  are  all  powered  on  a  220V  or  3-phase  circuit.  This 
is  not  an  available  power  source  at  the  ARSENL  testing  facility.  For  this  reason,  the 
use  of  an  AC  motor  was  eliminated  from  further  consideration. 

•  DC  motors  in  the  10-12  HP  range  require  battery  arrays  for  power.  The  other  option 
would  have  been  to  use  a  DC  power  supply;  however,  an  8.9  kW  motor  intuitively 
requires  an  8.9  kW  power  supply.  Similar  to  the  issue  with  AC  motors,  8.9  kw  power 
supplies  require  an  input  voltage  of  220V  or  3-phase. 

•  Batteries,  unlike  power  supplies,  are  able  to  provide  extremely  high  currents  (up  to 
1100  amps  on  high-discharge,  lead-acid  cells).  Also,  the  current  is  available  at  any 
voltage  by  wiring  cells  in  series.  It  became  clear  that  this  would  be  the  ideal  solution 
to  power  the  launcher  motor.  Other  benefits  include: 

-  Full  mobility  of  the  system  without  a  power  chord. 

-  A  battery  array  for  the  main  drive  motor  could  also  provide  a  stable  source  of 
DC  energy  for  on-board  sensors  and  processors. 

The  primary  concern  with  using  a  battery  array  was  the  weight.  The  expected  high-current 
draw  required  for  launch  necessitates  the  use  of  high-capacity  batteries  that  can  provide 
50  launches  without  recharge.  Higher-capacity  batteries  are  larger  and  heavier.  Also,  the 
number  of  batteries  required  (voltage  requirement  for  the  motor)  was  still  unknown.  This, 
however,  was  the  only  available  option;  thus  work  on  this  solution  continued  with  an  em¬ 
phasis  on  minimizing  weight. 

Having  established  that  a  DC  motor  was  the  only  viable  option,  the  motor  selection  process 
turned  towards  the  selection  of  a  brushed  or  brushless  option.  A  brushless  motor,  as  the 
name  implies,  does  not  use  a  brush/split-ring  commutator  design  to  generate  the  fluctuat¬ 
ing  magnetic  field  required  for  operation.  Without  getting  into  the  specifics  of  the  design 
differences,  the  considerations  to  the  user  are: 
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Brushless  Motors 

1.  Brushes  are  essentially  the  only  element  of  a  DC  motor  that  requires  interval 
replacement.  Removing  these  all  but  eliminates  motor  maintenance.  As  a  result, 
brushless  motors  also  tend  to  last  longer  than  their  brushed  counterparts. 

2.  Brushless  motors  run  quieter  and  smoother  due  to  contactless  control  of  the 
motor’s  RPM.  This  means  they  are  more  efficient. 

3.  These  motors  require  sophisticated  speed  controllers  to  electronically  switch 
the  current  without  brushes.  Speed  controllers  add  cost  and  complexity  to  the 
design. 

Brushed  Motors 

1.  For  brushed  motors,  speed  controllers  are  not  necessary;  the  brushes  accom¬ 
plish  the  same  task  mechanically.  Elimination  of  a  speed  controller  reduces 
system  complexity  and  cost. 

2.  A  speed  controller,  like  any  electronic  component,  has  internal  resistance.  This 
has  a  negative  impact  on  power  available  to  the  motor.  For  applications  where  a 
surge  of  high  starting-current  is  desired  (high  torque),  brushed  motors  are  ideal. 

Given  that  brushed,  DC  motors  are  the  better  and  simpler  option  from  a  performance  per¬ 
spective,  this  was  the  selection  made.  The  use  of  standard  search-engine  techniques  to  find 
motors  in  this  HP  range  did  not  return  useful  results.  Rather,  the  author  turned  to  web¬ 
sites  targeted  at  modified,  high-performance  golf-carts.  Motors  used  for  these  vehicles  are 
in  the  power  range  required  for  the  launcher.  Of  the  available  manufacturers,  Motenergy 
presented  the  best  HP  for  cost.  Two  of  their  motors  met  the  performance  requirements,  the 
ME1003  and  the  ME1004.  The  motors’  specifications  are  shown  in  Table  5.5. 

In  some  cases,  more  power  is  better.  However,  when  acceleration  time  for  an  electric 
motor  is  key,  the  correct  amount  of  power  is  critical.  To  explain  why  that  is,  imagine 
the  installation  of  a  low-speed,  high-torque  electric  motor  designed  for  trains.  It  would 
certainly  satisfy  the  torque  and  HP  requirements,  but  the  high  armature  inertia  inherent 
with  high-torque  motors  would  take  far  too  long  to  accelerate.  At  the  other  end  of  the 
spectrum,  a  high-rpm  motor  that  derives  its  horsepower  from  RPM,  rather  than  torque, 
could  be  installed  with  a  gear  reduction.  These  motors  accelerate  almost  instantly  due  to 
their  low  armature  inertia.  This  former  was  the  attempted  application  in  POC-1.  Knowing 
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Table  5.5:  Motenergy  Motor  Specifications 


Specification 

ME1003 

ME1004 

HP  Continuous 

15.4 

10.75 

HP  Peak 

30.8 

21.0 

Voltage 

72  Volts 

48  Volts 

Speed 

3700  RPM  @  72V,  Unloaded 

3700  RPM  @  48V,  Unloaded 

Size 

8”  Diameter,  7.4”  long 

8”  Diameter,  6.4”  long 

Weight  (Pounds) 

39 

32 

Armature  Inertia  (oz-in2) 

1464 

1093 

Rated  Torque  (in-lb) 

336.3 

214.4 

Stall  Torque  (in-lb) 

955.8 

610.56 

that  it  did  not  work,  and  reasoning  that  an  excessively  oversized  motor  would  also  not  work, 
research  was  conducted  to  determine  what  the  optimal  answer  should  be. 

A  1998  presentation  given  by  Richard  Armstrong  on  load-to-motor  inertia  mismatch  holds 
the  answer.  In  his  study,  it  is  shown  that  the  optimal  load-to-rotor  inertia  ratio  for  acceler¬ 
ation  and  positioning  is  1:1  [36].  The  maximum  suggested  ratio  is  10:1.  On  a  simplified 
level,  the  reason  behind  this  is  because  small  motors  with  low  rotor  inertias  have  a  difficult 
time  producing  motion  in  a  higher  inertia  system.  Alternatively,  a  motor  with  substantially 
higher  rotor  inertia  has  little  difficulty  with  the  system,  but  the  motor  must  now  overcome 
its  own  internal  inertia. 

The  findings  in  the  presentation  suggested  the  ME  1003  was  not  only  overkill  for  the  system, 
but  it  would  also  degrade  the  acceleration  performance.  Additionally,  the  ME  1003  required 
a  72  Volt  power  source.  In  comparison  to  the  ME  1004,  that  is  the  addition  of  two  extra 
batteries,  and  the  weight  penalty  was  undesired.  Therefore,  an  order  was  placed  for  the 
ME  1004  to  be  implemented  in  POC-3.  Also,  the  sprocket  sizing  was  adjusted  to  optimize 
the  system. 


5.4.4  Sprocket  Optimization 

The  characteristics  of  the  system,  as  configured  in  POC-2,  and  the  motor  are  shown  side- 
by-side  in  Table  5.6 

As  this  discussion  commences,  it  should  be  mentioned  that  the  duty  cycle  for  peak  HP 
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Table  5.6:  System  and  Motor  Characteristics 


Specification 

ME1004 

POC-2  Chain  Assembly 

HP  Continuous/Peak 

10.75/21.0 

14.41 

Speed 

3700  RPM  @  48V,  Unloaded 

3924 

Armature  Inertia  (oz-in2) 

1093 

720.9 

Rated/Stall  Torque  (in-lb) 

214.4/610.56 

191.6 

and  twice  the  rated  torque  is  five  minutes  continuous.  With  an  expected  duty  cycle  of  0.4 
seconds  on,  followed  by  18  seconds  off,  peak  values  were  usable  power  figures  without 
harming  the  motor. 

The  online  conveyor  belt  calculator  was  again  used  to  adjust  sprocket  sizing  to  match  the 
system  with  the  selected  ME  1004  motor.  Adjustments  were  made  to  the  drive,  primary,  and 
secondary  sprocket  diameters.  The  goal  was  to  reduce  the  RPM  requirement  and  match  the 
load-to-rotor  inertia  while  remaining  within  the  motor’s  power  and  torque  limitations. 

The  chosen  configuration  for  follow-on  iterations  was  7-inch  drive  sprockets  with  a  2:1 
gearing  ratio  (primary  and  secondary  sprocket  diameters  of  two  and  four  inches,  respec¬ 
tively).  This  produced  the  changes  shown  in  Table  5.7.  The  components  for  these  changes 
would  be  ordered,  but  did  not  arrive  in  time  for  POC-3.  The  sprocket  changes  would  not 
be  implemented  until  POC-4. 


Table  5.7:  Modified  System  and  Motor  Characteristics 


Specification 

ME1004 

Modified  Chain  Assembly 

HP  Continuous/Peak 

10.75/21.0 

14.75 

Speed 

3700  RPM  @  48V,  Unloaded 

3227 

Armature  Inertia  (oz-in2) 

1093 

975.4 

Rated/Stall  Torque  (in-lb) 

214.4/610.56 

386.3 

Notice  the  HP  requirement  increases  from  the  configuration  used  in  POC-2,  but  the  inertia 
ratio  of  the  motor  and  the  chain  assembly  is  nearly  1:1.  Also,  the  RPM  requirement  for 
the  chain  is  reduced  to  3,227.  This  allows  for  an  11.4%  reduction  in  the  motor’s  available 
RPM  to  account  for  loading. 
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5.4.5  Battery  Sizing 

Next,  an  appropriate  battery  array  needed  to  be  ordered  for  the  motor.  Knowing  the  ex¬ 
pected  torque  requirement  was  386.3  oz-in2,  the  predicted  current  was  calculated  based 
on  the  motor’s  torque  constant  (this  relates  torque  to  amperage  with  units  of  in-lbs/amp). 
This  value  was  found  to  be  346.4  amps.  This  high  current-rating  rules  out  most  battery 
chemistries,  with  the  exception  of  lead-acid.  Often  listed  as  Pb  (lead),  these  batteries  are 
considerably  heavier  than  their  lithium-polymer  (LiPo)  counterparts,  but  the  allowable  dis¬ 
charge  rate  is  much  greater.  They  are  also  less  expensive. 

Knowing  the  expected  discharge  current  and  the  time  of  discharge,  the  team  could  derive 
the  required  battery  capacity.  For  a  conservative  discharge  time  of  0.5  seconds  at  350  amps 
for  50  launches,  the  battery  capacity  consumed  would  be  2.43  amp-hours  (Ah).  The  rate 
of  discharge  is  directly  related  to  battery  capacity,  and  the  minimum  capacity  capable  of 
a  350-amp  discharge  rate  occurs  at  approximately  17  Ah  capacity  batteries.  The  batteries 
selected  have  a  22  amp-hour  capacity  with  a  750-amp  discharge  rating.  Using  the  same 
assumptions  for  current  draw,  these  batteries  are  capable  of  providing  approximately  450 
launches  before  recharge.  They  are  also  relatively  lightweight  for  a  Pb  battery  at  14.5 
pounds  apiece.  Four  were  ordered  and  wired  in  series  for  a  total  of  48  Volts. 

5.5  Proof-of-Concept  3 

POC-3  was  the  first  concept  that  utilized  a  power  source  capable  of  launching  the  UAV. 
This  was  the  first  concept  capable  of  meeting  all  launching-related  performance  require¬ 
ments.  A  CAD  overview  of  the  system  is  shown  in  Figure  5.19,  and  a  close-up  of  the 
supporting  structure  for  the  motor  is  shown  in  Figure  5.20. 

5.5.1  Testing 

All  tests  for  POC-3  were  conducted  in  a  laboratory  setting.  Retired  Zephyr  aircraft  were 
used  for  launching  tests,  which  allowed  the  team  to  push  the  envelope  in  terms  of  g-loading 
and  other  forces  exerted  on  the  aircraft.  The  methodology  and  elements  tested  were: 
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Figure  5.19:  POC-3  Overview  with  UAV 


Figure  5.20:  POC-3  Motor  Mount 


UAV  Interface 

1 .  The  interface  was  tested  for  its  ability  to  transfer  power  from  the  chain  to  the 
UAV  (R16).  The  test  was  performed  by  attaching  the  interface  to  the  aircraft, 
and  then  clipping  the  interface  into  the  chain.  Power  was  applied  to  the  system, 
but  the  voltage  was  limited  to  reduce  end-speed.  Once  it  could  be  verified  that 
the  system  was  operating  safely,  the  voltage  limits  were  progressively  raised 
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until  the  full  48  Volts  were  applied.  However,  the  UAV  was  not  attached  for 
tests  conducted  above  24  Volts.  Launching  the  UAV  at  full-velocity  indoors 
was  not  an  option. 

2.  It  was  also  desired  to  determine  what  pitching  moments,  if  any,  were  generated 
during  ejection  of  the  interface  from  the  chain  (R17).  Conducted  in  the  same 
series  of  tests  at  12  and  24  Volts,  high-speed  cameras  were  used  to  record  the 
UAV  at  the  departure  end.  Playback  results  were  then  analyzed. 

Motor  Selection 

1.  To  alleviate  the  highest  risk  element  and  greatest  unknown,  it  was  desired  to  val¬ 
idate  that  the  motor  was  capable  of  generating  the  necessary  power  for  launch 
(Rl,  R13).  For  this,  velocity  profiles  were  recorded  at  the  full  48  Volts  to  deter¬ 
mine  chain  speed. 

2.  The  real-time  current  was  measured  to  compare  tested  results  with  theoretical 
values.  These  were  used  to  validate  the  mathematical  model  of  the  system. 

The  testing  results,  along  with  mitigating  design  changes,  are  presented  by  component  in 
the  following  sub-sections. 

5.5.2  Motor  Results  and  Model  Verification 

It  was  encouraging  the  first  time  power  was  applied  to  the  motor.  Even  though  the  initial 
series  of  tests  were  safety-limited  to  12  volts  (low  velocity),  the  motor  showed  no  signs  of 
hesitation.  To  the  naked  eye,  acceleration  was  instant.  There  was  not  a  throttle  implemented 
for  these  tests,  power  was  applied  via  a  contactor  (an  electrically-controlled  switch  that 
provides  on/off  functionality  for  high-current  systems),  and  the  motor  pulled  as  many  amps 
as  were  necessary  to  reach  maximum  RPM.  For  a  launcher  application,  this  should  have 
been  the  ideal  setup  -  maximum  power  as  quickly  as  possible.  However,  further  testing 
would  show  this  was  not  an  accurate  prediction. 

Motor  voltages  applied  were  progressively  increased  in  12-volt  increments  until  the  full  48 
volts  was  reached.  Peak  amperages  of  each  test  were  recorded  for  model  verification,  and 
high-speed  film  was  captured  to  analyze  the  velocity  profile  of  the  chain  during  launch.  It 
was  initially  noticed  that  the  ammeter  was  measuring  amperages  far  greater  than  expected. 
The  model  had  shown  that  an  eight-foot  launcher  should  require  233.7  in-lbs  of  torque. 
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Factoring  out  the  1.5  safety  margin,  this  becomes  155.8  in-lbs.  Using  the  torque  constant 
for  the  motor,  the  system  should  have  required  140  amps,  but  the  test  showed  that  437  amps 
were  drawn. 

At  first,  it  was  assumed  that  the  online  calculator  used  to  model  the  launcher  was  a  poor 
approximation  of  the  system.  Then,  video  analysis  showed  the  motor  was  accelerating  the 
chain  to  design  velocity  in  only  three  feet.  Therefore,  the  constant  acceleration  assumption 
used  for  the  timing  input  in  the  online  calculator  was  not  accurate. 

To  correct  the  model,  the  analysis  was  performed  on  a  one-foot  section  of  the  launcher 
rather  than  the  full  length.  This  resulted  in  the  linear  assumption  being  a  better  approx¬ 
imation.  Also,  the  foot  selected  for  comparison  was  determined  by  where  the  maximum 
acceleration  took  place  (this  was  usually  the  second  foot  of  the  launch  profile).  Logically, 
the  torque  required  for  that  foot  of  motion  is  what  corresponds  to  the  peak  amperages  that 
were  recorded.  With  these  corrections  implemented,  the  torque  requirements  calculated 
by  the  model  were  validated  with  a  maximum  difference  of  only  six  percent  from  testing 
results. 

Initially,  the  team  was  pleased  with  the  motor’s  ability  to  accelerate  the  system.  One  of  the 
two  originally  identified  high-risk  design  factors  had  been  eliminated.  Unfortunately,  the 
acceleration  limit  had  been  exceeded.  The  motor  was  capable  of  launching  the  aircraft  in 
three  feet,  but  it  was  generating  an  average  of  16.5g  to  accomplish  this.  For  a  five-pound 
aircraft,  that  is  82  pounds  of  force  transferred  at  the  interface  attach  points.  While  it  was 
never  tested,  it  was  reasonable  to  assume  this  amount  of  force  would  cause  structural  failure 
of  the  foam  wing. 

To  solve  the  issue,  speed  controllers  had  to  be  implemented.  The  selected  controller  pro¬ 
vided  up  to  300  amps  of  continuous  current.  The  now  validated  model  for  the  twelve-foot 
prototype  indicated  213  amps  would  be  required.  Therefore,  it  was  reasoned  a  300-amp 
controller  should  be  sufficient.  It  was  slightly  undersized  for  the  amperage  requirements 
on  the  eight-foot  POC,  but  the  end-speed  was  electronically  limited  to  lower  the  amperage 
requirements  and  accommodate  testing.  The  net  result  from  a  performance  viewpoint  was 
that  acceleration  was  now  constant,  and  the  g-loading  was  reduced  to  acceptable  levels. 
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5.5.3  Interface  Results 

The  UAV  interface  was  not  able  to  provide  adequate  holding  power  for  launch.  Immediately 
upon  power  application,  the  interface  pulled  out  of  the  chain.  Modifications  to  the  interface 
were  delayed  until  the  speed  controller  was  received.  It  was  reasoned  the  speed  controller 
might  reduce  the  initial  jolt  sufficiently  enough  for  the  clip  to  work.  Upon  arrival  of  the 
controller,  testing  showed  the  high-impulse  start  was  reduced,  but  the  clip  still  pulled  out. 
Several  design  changes  were  attempted  to  mitigate  the  issue,  but  all  were  unsuccessful  until 
attachments  were  added.  The  evolution  of  these  modifications  is  shown  in  Figure  5.21. 


Figure  5.21:  UAV  Interface  Versions 


Version  2  This  was  the  result  of  the  stakeholders’  request  to  reduce  the  size  and  streamline 
the  UAV  interface.  Notice  that  the  functionality  did  not  change  from  the  interface 
presented  for  POC- 1 . 

Version  3  To  achieve  more  holding  power,  a  third  prong  was  added.  Also,  the  gap  in 
the  peg  was  shifted  forward.  The  energy  transfer  during  launch  was  entirely  on  the 
rear  face  of  the  pegs.  Shifting  the  gap  allowed  for  the  same  clip-in  functionality 
while  strengthening  the  chain  contact  points.  These  changes,  however,  were  still  not 
adequate. 

Version  4  It  was  noticed  during  testing  that  the  interface,  when  attached  to  the  UAV,  was 
not  flush  with  the  chain  prior  to  insertion.  There  was  an  angle  between  the  UAV 
hook  and  chain  that  was  not  considered.  The  version  shown  in  Figure  5.21  was  15 
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degrees  to  emphasize  the  correction  that  was  made.  Final  value  was  found  to  be  ten 
degrees.  Although  this  did  improve  the  interface,  correcting  the  mating  angle  still 
did  not  solve  the  issue. 

At  this  point,  it  was  determined  the  risk  mitigation  plan  would  need  to  be  implemented, 
and  attachments  were  added  to  the  chain.  These  were  initially  avoided  because  the  clip- 
in  concept  did  not  require  positioning  of  the  chain  assembly  to  attach  the  UAV.  Once 
attachments  are  added,  the  UAV  will  only  connect  to  a  single  point  (where  the  attachment 
is)  on  the  chain.  Operationally,  this  meant  the  attachment  would  need  to  be  re-positioned 
to  the  correct  location  following  each  launch.  The  positioning  function  would  take  time, 
and  it  also  required  a  speed  controller,  which  is  why  attachments  were  avoided.  However, 
as  discussed,  the  same  series  of  tests  revealed  it  would  be  necessary  for  launch,  as  well. 

The  use  of  chain  attachments  allows  for  virtually  unlimited  interface  design  options.  The 
first  concept  developed  is  shown  in  Figure  5.22. 


Figure  5.22:  Velcro  UAV  Interface 
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The  Velcro  used  is  a  double-mushroom  design  as  opposed  to  the  standard  hook-and-loop. 
This  type  of  Velcro  does  not  quickly  wear  over  time,  and  it  provides  an  audible  and  tactile 
“click”  when  fully  mated.  Also,  it  has  a  stronger  holding  force  in  shear  than  normal  Velcro, 
which  was  ideal  for  the  design.  Rather  than  have  the  sprocket  eject  the  clip  as  before, 
the  PVC  guide  rails  would  support  the  UAV  while  the  chain  rolls  away  and  breaks  Velcro 
contact  with  the  UAV’s  interface.  A  high-speed  frame  capture  from  the  recorded  test  series 
shows  the  functionality  of  this  concept  in  Figure  5.23. 


Figure  5.23:  Velcro  UAV  Interface  Release 

It  was  hoped  the  Velcro  would  be  sufficiently  strong  to  remain  attached  during  launch. 
However,  testing  revealed  -just  as  it  did  with  the  clip-in  interface  -  that  it  would  immedi¬ 
ately  break  away  during  the  launch  attempt.  Another  point  of  contact  with  the  UAV  would 
be  required.  A  stakeholder  meeting  was  held  to  discuss  options,  and  it  was  decided  that 
the  addition  of  a  wedge  interface  pushing  against  the  UAV  motor  mount  was  the  best  solu¬ 
tion.  This  change  allowed  for  the  wedge  to  absorb  most  of  the  energy  transfer,  and  testing 
showed  the  Velcro  remained  engaged.  The  reconfigured  attachment  method  is  shown  in 
Figure  5.24. 
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Figure  5.24:  Wedge  UAV  Interface  Method 


This  method  proved  highly  reliable  with  zero  failures  during  laboratory  testing.  It  should 
be  noted  that  these  tests  were  conducted  at  half  velocity  to  facilitate  catching  of  the  UAV 
following  the  launch.  To  simulate  full-speed  tests,  the  velocity  profile  was  programmed 
to  continue  acceleration  at  the  same  rate  (g-loading  on  the  aircraft  and  interface),  but  stop 
acceleration  halfway  down  the  launcher.  Also,  these  tests  were  able  to  confirm  there  was 
no  pitching  of  the  UAV  caused  by  the  Velcro  release.  The  PVC  support  rails  were  set  up  to 
contact  the  aircraft  at  the  same  longitudinal  point  on  the  UAV  as  the  nose  hold-down.  This 
way,  the  brief  pull-down  force  experienced  during  detachment  had  a  moment  arm  of  zero, 
thereby  ensuring  it  would  not  pitch  the  aircraft. 

The  stakeholders  were  pleased  with  the  results,  and  this  was  the  interface  design  selected 
for  the  prototype.  A  critical  design  flaw  was  later  revealed,  but  this  issue  was  not  discovered 
until  operational  field-testing.  It  will  be  discussed  in  Chapter  6.  For  now,  the  interface  was 
functioning  as  intended. 


5.6  Proof-of-Concept  4 

One  final  change  was  made  to  the  POC  prior  to  full-system  testing  and  prototype  devel¬ 
opment.  The  total  system  weight  with  batteries  was  over  160  pounds.  In  accordance  with 
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requirements  24-26,  motorized  wheels  were  necessary.  During  the  research  effort  to  source 
a  primary  drive  motor,  a  wheel-motor  manufacturer  with  an  ideal  solution  had  been  found. 
Their  geared  wheel-motor  is  designed  for  a  300-pound  robot,  and  can  be  controlled  with 
the  same  type  of  speed  controller  used  for  the  launcher  motor.  The  speed  controller  manu¬ 
facturer  produces  a  dual-channel  version  (150  amps  per  channel),  that  allows  for  indepen¬ 
dent  control  of  each  motor.  This,  in  combination  with  a  castoring  tail-wheel,  allows  for  a 
zero-radius  turn.  The  modification,  prior  to  re-mounting  the  PVC  guide  rails,  is  shown  in 
Figure  5.25. 


Figure  5.25:  Motorized  Wheel  Integration 
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The  wheel  motors  added  60  pounds  to  the  design,  but  the  stakeholder  desired  the  afforded 
functionality  that  motorized  wheels  could  provide.  It  would  not  be  implemented  in  time 
for  the  prototype,  but  motorized  wheels,  in  combination  with  a  wind  and  heading  sensor, 
would  allow  for  automated  wind  correction.  They  also  reduce  the  physical  workload  of  the 
ground  technicians  when  relocating  the  system. 

5.6.1  Testing 

All  mechanical  aspects  of  the  system  were  now  integrated,  which  allowed  for  the  first 
series  of  tests  in  a  relevant  environment.  Prior  to  this,  all  testing  had  been  conducted  in  a 
laboratory.  These  tests  were  the  first  demonstration  of  the  system’s  ability  to  launch  the 
UAV  at  full  speed. 

Ten  launches  were  scheduled  into  the  testing  plan,  but  only  six  were  accomplished.  The 
motor  mount  on  the  UAV  was  bending  as  a  result  of  the  launch,  and  on  the  sixth  attempt, 
the  motor  mount  failed.  However,  this  was  not  a  major  concern  for  the  following  reasons: 

1.  The  testing  environment’s  close  proximity  to  an  airport  required  the  use  of  a  tethered 
UAV  for  safety.  ARSENL  only  has  one  of  these  in  their  inventory,  and  it  is  in  poor 
condition.  The  mechanical  soundness  of  the  motor  mount  was  in  question  prior  to 
the  tests  commencing. 

2.  The  mount  itself,  which  is  made  out  of  aluminum  angle,  is  half  the  thickness  as  the 
operational  UAVs.  Also,  it  is  protruding  excessively  from  the  foam  support  structure. 
This  allows  for  torque  to  be  transmitted  to  the  foam  structure  that  would  not  be  an 
issue  for  the  non-tethered  aircraft.  Figure  5.26  illustrates  the  difference. 

3.  The  UAV  tested  in  the  laboratory  has  a  motor  mount  that  is  fully  seated  in  the  foam 
like  the  operational  models.  This  UAV  underwent  more  than  30  launches  at  up  to  1.5 
design  load  (6g)  without  bending  or  failure. 

For  these  reasons,  the  failure  was  attributed  to  the  UAV,  not  the  launcher.  All  other  aspects 
of  the  launch  were  favorable. 
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Aluminum  Mount 
Glued  Into  UAV 


Aluminum  Mount 
Glued  Into  UAV 

Figure  5.26:  UAV  Motor  Mount  Comparison 

5.7  Proof-of-Concept  System  Review 

POC-4  marked  the  completion  of  the  proof-of-concept  development  effort.  Technical  risks, 
system  costs,  and  technology  readiness  levels  were  being  tracked  throughout,  but  were  not 
specifically  presented  in  the  interest  of  brevity.  Instead,  a  summary  of  the  system  status  is 
reviewed. 


5.7.1  Risk  Assessment 

As  discussed,  sourcing  a  motor  and  the  chain  design  were  the  critical  design  risks.  These 
two  elements  of  the  system  presented  the  most  issues,  as  well.  Field-testing  conducted 
with  POC-4  confirmed  functionality  of  these  systems.  Therefore,  there  was  a  high  level  of 
confidence  that  all  requirement  thresholds  would  be  achievable  by  the  prototype. 
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5.7.2  System  Costs 

Usually,  a  significant  amount  of  time  is  invested  into  managing  cost.  For  this  developmental 
effort,  however,  the  funding  available  was  known  to  be  in  excess  of  what  was  required.  Of 
the  $10,000  allotted,  conservative  estimates  with  significant  risk  allocations  showed  only 
$6,000  should  be  required.  Also,  ARSENL  had  already  invested  approximately  $1,600 
into  the  construction  of  POC-1  prior  to  the  establishment  of  the  $10,000  cap.  Therefore, 
the  net  amount  funded  was  $11,600.  To  date,  $3,126.94  was  invested  into  the  development 
of  POC-1  through  POC-4.  This  left  approximately  $8,500  for  prototype  construction.  The 
only  significant  change  planned  was  the  use  of  extruded  aluminum  for  the  frame.  The 
estimate  for  this  was  approximately  $1,500,  ergo  the  budget  was  thought  to  be  in  excellent 
condition  with  a  $7,000  buffer  for  unforeseen  expenses. 

5.7.3  TRL  Assessment 

POC-1  satisfied  the  requirements  to  establish  the  readiness  level  at  TRL-2.  This  level 
is  where  invention  begins,  and  basic  principles  are  observed.  The  Defense  Acquisition 
Guidebook  (DAG)  notes  that  applications  at  this  level  “are  speculative  and  there  may  be  no 
proof  or  detailed  analysis  to  support  the  assumptions”  [19]. 

POC-2  allowed  for  individual  component  experimentation  to  partially  satisfy  TRL-3.  The 
types  of  tests  that  took  place  are  characteristic  of  TRL-3,  but  the  system  still  lacked  the 
ability  to  validate  analytical  predictions  that  are  required  for  TRL-3. 

POC-3  validated  the  analytical  models  for  TRL-3,  and  it  also  allowed  the  system  to  be 
tested  at  TRL-4.  The  primary  characteristic  of  a  system  at  TRL-4  is  that  components  have 
been  integrated  and  proven  to  work  together.  However,  it  is  still  “low  fidelity”  compared  to 
the  final  product  [19]. 

Lull  system  testing  of  POC-4  in  a  relevant  environment  satisfied  the  requirements  for  TRL- 
5.  To  progress  to  TRL-6,  the  system  required  automated  capabilities  and  sensors  that  were 
not  yet  coded  into  the  control  logic.  Lor  more  information  on  these  elements,  refer  to  [22]. 
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CHAPTER  6: 
Prototype  Development 


Referencing,  for  the  last  time,  the  systems  engineering  (SE)  process  shown  in  Figure  6.1,  it 
was  now  time  to  build  the  prototype  and  validate  it  against  system  requirements.  Prototype 
testing  and  validation  would  mark  research  completion. 
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Figure  6.1:  DOD  SE  Process  Overview,  from  [19] 


6.1  Overview 

As  a  jeu  de  mots  on  the  relatively  high-current  draw  observed  during  proof-of-concept 
(POC)  development,  it  was  decided  to  name  the  prototype  AMPPS.  The  acronym  stood  for 
“Automated,  Multi-Plane  Propulsion  System.” 

The  primary  goal  for  AMPPS  was  to  provide  ARSENL  with  a  solution  that  was  suitable 
for  long-term,  operational  testing.  POC-4  had  already  demonstrated  a  functional  baseline, 
what  it  lacked  was  any  kind  of  environmental  protection  or  structural  durability.  Also, 
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provisions  needed  to  be  made  for  the  integration  of  automated  systems  and  sensors.  This 
chapter  presents  an  overview  of  what  automated  capabilities  were  added,  but,  as  previously 
mentioned,  these  were  not  the  focus  of  this  study. 

For  chronological  clarity,  the  computer-aided  design  (CAD)  development  for  the  prototype 
began  shortly  after  the  construction  of  POC-1.  Schedule  constraints  required  a  design 
freeze  and  component  ordering  for  the  prototype  to  take  place  halfway  through  the  testing 
of  POC-4.  At  the  time  the  order  was  placed,  it  was  known  that  the  motor  selection  was 
adequate,  but  the  unmanned  aerial  vehicle  (UAV)  interface  had  not  been  tested.  The  original 
intent  was  to  validate  fully  the  proof-of-concept  before  investing  in  longevity  for  a  system 
that  was  still  unproven.  For  example,  the  one  inch  main  bearings  used  for  the  concepts  were 
approximately  $12  apiece.  Bearings  that  met  environmental  requirements  for  being  dust 
and  water  resistance  were  approximately  $85  apiece.  Fortunately,  the  POC  was  successful 
and  the  investment  worthwhile.  However,  this  order  of  development  is  not  recommended 
and,  as  will  be  shown,  issues  did  arise  as  a  result. 


6.2  Structural  Development 

Lessons  learned  from  the  development  of  the  RULE  design  suggested  that  extruded  alu¬ 
minum  was  an  ideal  choice  for  the  framing  material;  therefore,  this  was  selected  for  the 
structure.  Top  considerations  for  the  structural  layout  were: 

•  Attention  was  given  to  minimizing  the  weight  of  the  structure.  Several  methods  were 
used  to  accomplish  this  goal,  but  the  primary  focus  was  on  using  elements  of  the 
structure  for  multiple  purposes.  For  example,  the  mounting  support  for  the  wheel 
motors  are  sized  to  serve  as  the  battery  tray,  too.  This  eliminates  the  need  for  extra 
supports  just  to  mount  the  batteries. 

•  Sizing  of  the  structure  is  designed  to  allow  for  component  mounting  without  the  need 
for  custom  adaptors.  Various  ways  in  which  this  is  implemented  will  be  discussed  as 
the  design  is  presented. 

•  The  framing  would  be  delivered  cut  to  length  by  the  manufacturer.  However,  spare, 
uncut  stock  was  ordered  for  replacement  or  modifications.  This  material  is  delivered 
in  12-foot  lengths  that  would  have  to  be  cut  in-house.  For  this  reason,  dimensions 
of  the  launcher’s  structure  are  designed  in  one-inch  increments.  Without  computer- 
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controlled  machining,  cutting  a  six-inch  length  of  material  is  accomplished  more 
easily  than  cutting  a  6.125-inch  section. 

The  framing  overviews,  along  with  major  changes,  are  discussed  first.  This  will  be  followed 
by  an  explanation  of  the  features  for  the  final  iteration.  Figure  6.2  shows  an  overview  of 
the  first  evolution  of  the  frame.  Note  the  UAV  support  rails  are  reclined  in  the  CAD  to 
demonstrate  that  they  could  be  collapsed  for  transportation.  This  is  not  their  position  for 
launching  operations. 


Figure  6.2:  Prototype  Frame  (VI) 

Changes  incorporated  for  the  second  version  were: 

•  Version  1  (VI)  of  the  prototype  was  designed  using  extruded  aluminum  with  a  one 
inch  cross-section.  Due  to  the  long  center-span,  the  manufacturer  recommended 
switching  to  larger,  1.5-inch  framing  for  rigidity.  This  would  be  incorporated  into 
V2. 

•  The  wheel  motors  were  originally  mounted  to  the  upper  surface  of  the  battery  trays. 
With  this  configuration,  however,  the  design  was  unable  to  fit  through  a  standard 
doorway  (R23).  Therefore,  the  wheel  motors  were  moved  to  the  lower  surface  in 
order  to  reduce  the  width  of  the  structure. 

•  The  idler  sprockets  are  arranged  for  a  system  that  does  not  have  attachments.  This 
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means  the  chain  can  be  supported  from  either  side  without  an  issue.  Once  attach¬ 
ments  were  added,  the  chain  could  only  be  supported  from  the  inside  of  the  cir¬ 
cumference.  Otherwise,  the  attachments  would  interfere  the  idler  sprockets.  This 
principle  is  shown  in  Figure  6.3 


Motion  of  Chain 

- ► 


Motion  of  Chain 

- ► 


Figure  6.3:  Attachment  Binding  with  Idler  Sprockets 


The  second  version  (V2)  of  the  frame,  is  shown  in  Figure  6.4. 

Features  of  V2  and  the  changes  incorporated  for  the  third  and  final  version  were: 

•  The  manufacturer  of  the  wheel  motors  indicated  the  motors  could  be  configured  as  a 
direct-drive  system.  This  version  assumes  the  wheels  would  need  to  be  mounted  on 
separate  shafts  (to  support  the  weight)  and  driven  with  a  chain  reduction. 

•  The  height  of  the  launcher  is  set  at  40  inches  as  a  human-factors  consideration  for 
loading  UAVs.  This  height  corresponds  to  an  approximate  average  where  the  tech- 
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Figure  6.4:  Prototype  Frame  (V2) 

nician  would  not  have  to  bend  over  to  secure  the  UAV.  The  stakeholder  indicated 
compactness  was  of  greater  concern  than  ergonomics;  therefore,  the  height  would  be 
reduced  in  V3. 

•  An  error  by  the  author  in  transposing  the  battery  dimensions  resulted  in  inaccurate 
sizing  for  the  CAD.  They  were  actually  much  smaller,  which  allowed  for  new  mount¬ 
ing  locations  in  V3. 

•  The  various  sensors  and  electronics  were  originally  planned  to  be  located  underneath 
the  white  plate  used  to  mount  the  linear  chain  guide.  The  new  battery  location  would 
allow  for  them  to  be  mounted  on  trays  where  the  batteries  are  shown  in  this  version. 
This  is  a  better  location  for  minimizing  the  lengths  of  wire  connections. 

The  third  configuration  (V3),  which  represents  the  design  that  was  ordered,  is  shown  in 
Figure  6.5.  The  specifics  of  this  design  are  discussed  in  detail  in  the  next  section. 
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Figure  6.5:  Prototype  Frame  (V3) 

6.3  Structural  Design  Elements 

The  first  design  consideration  was  the  dimensions  of  the  center  section  used  to  support  the 
roller  chain  assembly.  The  height  was  determined  by  the  mounting  pattern  of  the  chosen 
main  bearings.  The  width  was  driven  by  the  availability  of  six-inch  wide  Lexan  sheets  used 
to  support  the  linear  chain  guide.  Length  for  the  drive  section  was  selected  at  12  feet  in 
accordance  with  chosen  design  specifications  from  the  length  sensitivity  study.  The  height 
and  width  dependencies  are  shown  in  Figure  6.6. 

To  eliminate  the  need  for  conveyor-belt  tensioners,  the  idler  sprocket  is  mounted  on  vertical 
supports  that  permit  up  and  down  adjustments  of  the  location.  This  allows  for  tension  ad¬ 
justment  without  the  tensioners.  Also,  the  incorporation  of  a  metal  frame  means  the  struc¬ 
ture’s  tolerances  would  be  very  precise.  This  removes  the  need  for  the  angular  adjustment 
afforded  by  the  tensioners.  As  a  result,  the  main  bearings  do  not  require  adjustment;  there¬ 
fore,  they  were  screwed  directly  into  the  threaded  ends  of  the  extruded  aluminum.  Finally, 
the  removal  of  the  tensioners  mandated  that  the  motor’s  position  be  adjustable  to  allow  for 
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Figure  6.6:  Prototype  Drive  Section 


tensioning  of  the  power  transfer  chain  between  the  primary  and  secondary  sprockets.  This 
was  accomplished  by  mounting  a  horizontal  brace  with  enough  width  for  adjustment.  The 
motor  mount  is  shown  in  Figure  6.7. 


Figure  6.7:  Prototype  Motor  Mount 
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Recall  that  the  primary  and  secondary  sprockets  for  the  POC  were  located  outside  of  the 
main  bearings.  To  guard  the  chain  assembly,  and  also  to  remove  any  torque  generated  by 
the  tension  of  the  power  transfer  chain,  these  are  relocated  inside  the  bearings  as  shown  in 
Figure  6.8. 


Figure  6.8:  Prototype  Sprocket  Configuration 


Finally,  a  standard  U-bolt  is  added  for  user  protection  from  the  driven  sprocket.  It  is  also 
meant  to  serve  as  a  capture  device,  should  the  main  launcher  chain  break  during  operation. 
The  application  is  shown  in  Figure  6.9. 
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Figure  6.9:  Prototype  Chain  Guard 


6.4  Construction 

While  CAD  is  certainly  a  useful  aid,  there  were  limitations.  For  example,  the  structural 
rigidity  of  the  aluminum  framing  could  be  calculated  in  CAD,  but  it  was  not  a  replace¬ 
ment  for  tactile  feedback.  Early  in  the  construction  process,  it  was  noticed  that  the  drive 
section  assembly  was  over-engineered.  Rigidity  appeared  to  be  far  greater  than  what  was 
necessary;  therefore,  the  lower  longerons  were  removed  in  the  center  section  as  shown  in 
Figure  6.10.  This  modification  removed  32  pounds  of  weight  from  the  prototype  without 
sacrificing  functionality. 

Another  design  change,  shown  in  Figure  6.10,  was  the  removal  of  a  single  tailwheel  in 
favor  of  dual-castering  tailwheels.  This  element  was  changed  from  the  CAD  for  increased 
stability. 

The  next  major  alteration  made  during  construction  was  the  UAV  support  rails.  Recall  that 
the  use  of  Velcro  for  the  UAV  nose  hold-down  required  the  support  rails  to  contact  the 
aircraft  at  the  same  longitudinal  location  as  the  interface.  This  was  to  prevent  pitching  of 
the  UAV’s  nose  during  interface  release.  As  a  consequence  of  ordering  the  frame  prior  to 
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Figure  6.10:  Prototype  Removal  of  Lower  Longeron 


completing  POC  interface  testing,  modifications  to  the  metal  structure  had  to  be  made  to 
reflect  the  requirement.  To  accomplish  this,  the  support  arms  are  cut  down,  and  the  rails  are 
rotated  on  edge.  This  modification  also  provides  an  added  benefit:  it  serves  as  a  propeller 
guard  during  launch  to  prevent  wind-milling.  Figure  6.11  shows  the  original  support  rail 
location  on  the  right,  and  the  change  (prior  to  cutting  the  support  arm)  on  the  left. 
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Figure  6.11:  UAV  Guide  Rail  Modification 


To  accept  the  required  electrical  suite,  Lexan  shelves  are  built  into  the  front  legs.  Also,  a 
power  switch  control  panel  is  mounted  to  the  rear  UAV  support  rail  arm.  These  features  are 
shown  in  Figure  6.12  and  Figure  6.13. 
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Figure  6.12:  Lexan  Shelving  for  Electronic  Suite 


Figure  6.13:  Power  Switch  Control  Panel 


The  final  construction  elements  are  shown  in  Figure  6.14.  The  last  modification  from 
the  CAD  was  the  relocation  of  the  idler  sprocket  to  the  front-leg  supports.  This  ensures 
clearance  of  the  UAV  interface  wedge  with  the  motor  shaft,  and  also  eliminates  the  need 
for  extra  mounting  structure.  Also  shown  is  the  3-D  printed  mounting  solution  for  the 
LCD  information  screen.  The  case,  along  with  the  UAV  interface,  are  the  only  custom 
components  on  the  system. 
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Figure  6.14:  LCD  Screen  and  Idler  Sprocket  Mount 


6.5  Sensor  Integration  Overview 

This  author  did  not  develop  the  sensory  and  electrical  systems,  but  they  are  essential  to 
the  operation  of  the  launcher.  Therefore,  an  overview  of  the  sensor  suite  and  automated 
capabilities  is  required.  For  more  detailed  information  on  any  of  these  sub-systems,  refer 
to  [22], 
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Wireless  Operation 

All  commands  (launch,  slow-speed  chain  positioning,  driving  the  wheel  motors)  are 
accomplished  wirelessly  via  a  Bluetooth  controller.  This  allows  for  remote  opera¬ 
tion  of  the  launcher  during  relocation  and  also  standoff  distance  for  the  technician 
during  launch.  All  functions  require  two-handed  button  combinations  to  reduce  the 
likelihood  of  accidental  command  inputs. 

Safety 

The  system  has  multiple  fail-safes  to  ensure  user  safety.  Starting  with  the  electri¬ 
cal  system,  the  battery  bank  is  hard-wired  into  a  manual  On/Off  switch.  With  this 
switch  off,  no  power  is  available  to  any  part  of  the  system.  Once  the  master  switch 
is  engaged,  the  control  panel  at  the  rear  of  the  launcher  is  used  to  selectively  provide 
power  to  the  main  motor  speed  controller,  the  wheel  motor’s  speed  controller,  and 
the  on-board  microcomputer.  These  switches  are  hard-wired  as  well;  therefore,  no 
current  can  flow  to  the  motors  or  computer  with  them  in  the  off  position. 

Software-based  logic  in  the  speed  controllers  does  not  allow  them  to  send  commands 
to  the  motors  without  positive  identification  of  the  microcomputer.  Should  control 
signals  be  lost,  the  controllers  defaulted  to  off.  To  prevent  a  runaway  situation  of 
any  kind,  a  kill  button  is  programmed  into  the  wireless  controller  that  electronically 
commands  a  main  contactor  to  open.  This  cuts  power  to  the  entire  battery  array. 

For  launch  safety,  sonar  sensors  are  mounted  to  the  near  and  far  end  of  the  launcher. 
Launch  commands  are  ignored  if  any  object  is  detected  within  the  programmed  sen¬ 
sor  range. 

Launch  Control 

A  highly-sophisticated  speed  controller  manages  the  launcher’s  main  motor.  The 
motor  does  not  contain  hall  sensors;  thus,  the  RPM  cannot  be  directly  measured. 
For  control,  open-loop  current  limiting  is  used  in  combination  with  timing  functions 
to  produce  linear  throttle  responses.  The  timing  functions  are  commanded  from  a 
separate  microcomputer  on  board  the  launcher.  The  same  timing  function  is  also 
utilized  to  automatically  shut  off  power  to  the  motor  after  a  launch  is  complete. 
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Wheel  Motor  Control 


A  two-channel  version  of  the  main  motor’s  speed  controller  is  used  to  independently 
drive  the  wheel  motors.  Joystick  commands  received  from  the  wireless  controller  are 
proportional  for  smooth  steering  and  speed  control  when  relocating  the  launcher. 

Communication 

Rapidly  launching  a  high  number  of  visually-identical  UAVs  makes  aircraft  identi¬ 
fication  difficult.  To  mitigate  this,  each  aircraft  is  embedded  with  a  radio-frequency 
identification  (RFID)  tag.  To  read  the  data,  a  RFID  reader  is  mounted  where  the  UAV 
is  loaded  for  launch.  The  LCD  screen  displays  the  aircraft  information  for  both  the 
technician  and  the  UAV’s  forward-looking  camera. 

To  sense  weather,  the  launcher  wirelessly  pulls  data  from  a  nearby  weather  station. 
On-board  heading  sensors  allow  for  crosswind  calculations.  Though  not  imple¬ 
mented,  this  could  later  be  used  to  alert  the  technician  if  the  launcher  were  outside 
of  cross-wind  limitations  for  the  UAV.  Also,  the  system  could  be  configured  to  auto¬ 
matically  reposition  into  the  wind. 

A  three-color  light  tower  is  mounted  to  the  front- wheel  supports  for  visual  confirma¬ 
tion  of  system  status.  The  lights  are  programmed  to  alert  the  technician  of  various 
system  states.  This  includes  any  unsafe  condition  (such  as  tripped  sonar  sensors), 
pending  launch  command  received,  and  ground  control  station  (GCS)-down  status. 
Also,  an  audible  alert  tone  is  programmed  to  sound  three  times,  warning  personnel 
in  the  area  that  a  launch  has  been  initiated. 


6.6  Testing 

The  final  round  of  testing  was  conducted  in  a  relevant  environment  at  the  Advanced 
Robotic  Systems  Engineering  Laboratory  (ARSENL)  testing  facility.  Recall  that  the  stated 
Technical  Readiness  Level  (TRL)  goal  for  the  prototype  was  to  reach  TRL-7.  This  readi¬ 
ness  level  requires  an  operational  environment.  To  consider  the  environment  operational  as 
opposed  to  relevant,  ARSENL  would  need  to  be  conducting  swarm  mission  sets.  Schedul¬ 
ing  conflicts  did  not  allow  for  the  launcher  to  be  used  for  this  purpose.  Instead,  the  testing 
conducted  for  POC-4  was  repeated,  but  with  operational,  untethered  UAVs.  Even  though 
the  same  tests  were  conducted,  the  launcher  now  qualified  as  a  “representative  model  or 
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prototype  system”  to  satisfy  the  definition  of  TRL-6. 

The  first  day  of  testing  revealed  the  critical  UAV  interface  issue  mentioned  during  POC-4 
testing.  All  previous  launch  tests  were  conducted  on  ARSENL-constructed  aircraft.  The 
Zephyr  II  platforms  used  for  this  round  of  testing  were  built  under  contract  by  a  third 
party.  This  was  the  first  time  these  aircraft  had  been  flown,  and  it  was  discovered  that  an 
inadequate  amount  of  glue  had  been  applied  to  the  motor  mount.  As  a  result,  the  aluminum 
motor  mount  delaminated  from  the  aircraft  during  the  second  launch  attempt.  This  is  shown 
in  Figure  6.15. 


Figure  6.15:  Delamination  of  Motor  Mount 


Although  the  fault  was  considered  to  be  with  the  aircraft,  100  UAYs  have  already  been 
ordered  under  the  same  contract.  This  element  of  the  UAV’s  construction  is  difficult  to 
strengthen  post-build,  necessitating  an  alteration  to  the  launcher. 

To  avoid  all  contact  with  the  motor  mount,  a  solution  needed  to  be  developed  rapidly  in 
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order  to  return  to  a  nose-only  UAV  interface.  The  primary  issue  with  previous  attempts 
was  the  failure  of  the  Velcro  to  hold  during  intial  power  application.  This  was  attributed 
to  its  inability  to  absorb  the  shearing  forces  associated  with  rapid  acelleration.  To  mitigate 
this  issue,  a  hybrid  of  the  previous  design  was  conceived.  A  backing  plate  was  integrated 
into  the  interface  component  that  mounted  to  the  roller  chain.  This  is  shown  in  blue,  along 
with  the  white  UAV  interface,  in  Figure  6.16. 


Figure  6.16:  Captured  UAV  Interface  Design 

The  concept  was  tested  the  next  day,  and  13  succesful  launches  were  conducted  using  the 
new  interface.  Figure  6.17  shows  the  UAV  immediately  prior  to  launch. 

Despite  successful  testing,  the  interface  was  not  without  issues.  Repeated  launches  of  the 
same  aircraft  showed  that  fatigue  was  occurring  in  the  UAV  launch  hook.  It  began  to 
flex  under  the  load  exerted  during  launch.  The  team  determined  more  support  structure 
was  needed  where  the  interface  contacted  the  UAV.  This  would  help  to  distribute  the 
force.  As  it  was,  all  forces  were  transmitted  directly  to  the  hook.  Time  did  not  permit 
the  implementation  of  this  change,  but  it  was  recorded  and  recommended  for  future  work. 
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Figure  6.17:  AMPPS  System  Testing  at  Camp  Roberts,  California 


6.7  Results 

The  success  of  a  system  is  measured  by  its  ability  to  satisfy  stated  requirements.  Some  of 
these  were  referenced  throughout  the  development,  but  a  complete  analysis  is  required  for 
system  validation.  The  requirements,  along  with  tested  results,  are  shown  in  Table  6. 1 . 


122 


Table  6.1:  Final  Testing  Results 


High-Level  Requirements 

Requirement  Measure 

Measures 

Units  of  Measure 

Objective  / 

Tested  Ca¬ 

Identifier 

Identifier 

Threshold 

pability 

R1 

MOE  1 

Launch  Rate  Performance 

Number  of  Aircraft 

>55/50 

Not  Tested 

R2 

MOE  2 

System  Availability 

Setup  Time  (Minutes) 

<13/15 

5 

R3 

MOE  3 

Launch  Reliability 

Number  of  Aircraft 

<0.5  /  1 

Needs  Fur¬ 
ther  Testing 

R4 

MOE  4 

Wind  Adaptability 

Adjustment  Time  (Sec¬ 
onds) 

<10/15 

2 

R5 

FUN  1 

Safety 

True  /  False 

True 

True 

R6 

CON  1 

Legacy  Adaptability 

True  /  False 

True 

True 

R7 

CON  2 

Use  of  COTS  Components 

Number  of  Custom 
Components 

<5 

2 

R8 

CON  3 

System  Length 

Length  (Feet) 

<16 

12 

R9 

CON  4 

Expense 

U.S.  Dollar 

<$10,000 

$6,346.59 

Performance  Requirements 

Requirement  Measure 

Measures 

Units  of  Measure 

Objective  / 

Tested  Ca¬ 

Identifier 

Identifier 

Threshold 

pability 

RIO 

MOP  1 

System  Reset  Time 

Time  Required  to  Reset 
Launcher 

<5/8 

4 

Rll 

MOP  2 

UAV  Load  Time 

Time  (Seconds) 

<8/10 

6 

R12 

MOP  3 

Portability 

Number  of  Personnel 

<1/2 

1 

R13 

MOP  4 

Launch  Velocity 

Velocity  (MPH) 

>40  /  35 

38 

Functional  Requirements 

Requirement  Measure 

Measures 

Units  of  Measure 

Objective  / 

Tested  Ca¬ 

Identifier 

Identifier 

Threshold 

pability 

R14 

FUN  2 

Environmental  Sensing 

True  /  False 

True 

True 

R15 

FUN  4 

System  Communication  Capability 
with  UAV 

True  /  False 

True 

True 

R16 

FUN  5 

UAV  Attachment  Capability 

True  /  False 

True 

True 

R17 

FUN  6 

UAV  Detachment  Capability 

True  /  False 

True 

True 

Constraint  Requirements 

Requirement  Measure 

Measures 

Units  of  Measure 

Objective  / 

Tested  Ca¬ 

Identifier 

Identifier 

Threshold 

pability 

R18 

CON  5 

System  Adaptability  with  UAV 

Force  (Pounds  Force) 

>20 

15 

R19 

CON  6 

Number  of  Technicians  Required  to 
Load  a  UAV 

Number  of  Technicians 

<2 

1 

R20 

CON  7 

System  Tie-Down  Adaptability 

True  /  False 

True 

True 

R21 

CON  8 

Environmental  Survivability 

True  /  False 

True 

True 

R22 

CON  9 

Environmental  Survivability 

True  /  False 

True 

True 

R23 

CON  10 

Maximum  Width  For  All  Orienta¬ 

Width  (Inches) 

<35 

32 

tions 

R24 

CON  11 

System  Weight 

Weight  (Pounds  Mass) 

<80 

N/A 

R25 

CON  12 

System  Weight 

Weight  (Pounds  Mass) 

<160 

N/A 

R26 

CON  13 

System  Weight 

Weight  (Pounds  Mass) 

<500 

245/True 

R27 

CON  14 

Number  of  Launchers  Required  to 
Accomplish  Launching  Mission 

Number  of  Launchers 

<2 

True 
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AMPPS  was  able  to  meet  or  exceed  all  requirement  thresholds  with  the  exception  of  two, 
for  which  testing  is  pending.  Requirement  1  (Rl)  stated  that  the  system  “shall  be  capable  of 
launching  50  aircraft  within  15  minutes.”  ARSENL’s  swarm  size  was  not  yet  large  enough 
to  facilitate  a  50-aircraft  launch;  therefore,  this  metric  could  not  be  tested.  However,  the 
system  was  tested  for  UAV  load  times  (Rl  1)  and  system  reset  time  (RIO).  The  total  time 
consumed  for  these  two  tasks  should  amount  to  the  launch  interval  time.  If  this  holds 
true,  the  system  is  capable  of  launching  an  aircraft  every  12  seconds  -  or  75  aircraft  in  a 
15-minute  window  -  thereby  satisfying  (Rl). 

The  second  untested  measure  is  related  to  the  launcher’s  reliability  (R3).  Time  constraints 
prevented  the  100  required  launches  from  being  conducted.  However,  the  new  UAV  inter¬ 
face  worked  with  no  launching  failures;  ergo,  the  system  was  on-track  to  accomplish  the 
threshold  for  this  requirement. 
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CHAPTER  7: 
Conclusion 


7.1  Summary  of  Findings 

The  research  goal  was  to  design  and  build  a  working  unmanned  aerial  vehicle  (UAV) 
launcher  prototype  that  met  all  cost,  schedule,  and  performance  requirements  for  the 
ARSENL  team.  From  beginning  to  end,  SE  practices  were  utilized  as  the  framework. 
The  core  benefit  afforded  through  the  use  of  systems  engineering  (SE)  is  that  it  provided 
the  necessary  tools  and  techniques  to  make  informed  decisions  throughout  the  process. 

The  methodical  approach  to  system  decomposition  allowed  the  author  to  fully  define  a  set 
of  requirements  that  would  satisfy  the  operational  need.  This  process  was  essential  to  the 
development  because  it  defined  precisely  what  the  prototype  must  “do”  to  provide  value 
to  the  stakeholders.  In  complex  systems,  it  is  easy  to  inadvertently  overlook  requirements 
that,  if  omitted,  would  render  the  solution  useless.  The  decomposition  process  was  used 
to  holistically  evaluate  a  total  system  solution  in  order  to  minimize  the  likelihood  of  this 
occurring.  Key  findings  observed  during  this  process  were: 

•  Stakeholder  preferences,  at  times,  were  difficult  to  interpret.  Sometimes,  the  stated 
need  cannot  be  directly  transferred  into  a  requirement.  For  example,  Advanced 
Robotic  Systems  Engineering  Laboratory  (ARSENL)  requested  a  launching  solu¬ 
tion  that  would  support  their  goal  of  50  UAVs  simultaneously  airborne.  It  was  the 
responsibility  of  the  development  team  to  determine  performance  parameters  (50  air¬ 
craft  in  15  minutes)  that  would  satisfy  that  need.  This  requirement  was  the  result  of 
analyzing  UAV  endurance  and  desired  combat  duration. 

•  In  other  instances,  the  stated  need  is  not  the  best  solution.  For  this  research,  the 
stakeholders  were  also  the  end-users.  The  focus  point  for  an  end-user  is  typically 
the  performance  parameters  that  are  lacking  from  their  current  system.  For  example, 
during  the  development  of  the  RULE  launcher,  it  took  ARSENL  five  to  ten  minutes 
to  launch  each  UAV.  They  attributed  the  long  cycle  time  to  the  bungee  launcher, 
but,  upon  observation  of  the  operations,  it  became  clear  that  procedural  inefficiencies 
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during  UAV  staging  were  actually  the  source  of  delayed  launch  intervals.  The  cap¬ 
stone  team  recommended  changes  that  resulted  in  the  one-to  1.5-minute  cycle  time 
quoted  at  the  beginning  of  this  research.  It  is  the  job  of  the  SE  team  to  analyze  the 
stated  need  and  determine  the  correct  course  of  action  from  a  holistic  point  of  view. 
This  cannot  be  accomplished  without  a  full,  top-down  decomposition  of  all  aspects 
affecting  the  system. 

Once  an  understanding  of  the  system  requirements  was  established,  a  market  analysis  was 
conducted  to  determine  if  an  existing  system  was  capable  of  meeting  said  requirements. 
Also,  this  process  was  utilized  to  establish  industry  design  standards  that  could  be  applied 
to  the  development  effort.  Results  indicated  that  a  unique  solution  was  warranted,  so  the 
design  process  commenced.  The  major  takeaway  from  this  phase  of  the  SE  process  was: 

•  Market  analysis  is  a  requirement  for  Department  of  Defense  (DOD)  acquisition  pro¬ 
grams  [19].  However,  it  is  an  easy  process  to  eliminate  for  personal,  or  small-scale, 
design  efforts.  The  importance,  however,  cannot  be  overstated.  Even  in  instances 
where  suitable  solutions  for  this  research  were  not  found,  the  process  of  thoroughly 
researching  existing  systems  was  crucial  to  the  concept  development  stage.  It  can 
sometimes  be  difficult  to  accurately  trace  the  specific  source  of  information  used  to 
make  a  decision.  Generally,  engineering  decisions  are  based  on  experience  and  data. 
Market  analysis  provided  the  experience  -  and  the  data  -  required  to  inform  many  of 
the  concept  decisions. 

Concept  generation  and  design  selection  were  accomplished  by  evaluating  the  proposed 
system  against  stated  requirements  and  build  feasibility.  The  limited  manufacturing  and 
construction  capabilities  of  the  small  development  team  had  to  be  taken  into  account  when 
selecting  a  concept.  Based  on  these  considerations,  a  belt-driven,  electrically  powered 
solution  was  selected. 

•  A  realistic  self-evaluation  was  critical  to  this  phase  of  development.  It  was  important 
to  factor  into  the  process,  schedule  and  team  limitations.  Even  for  large  engineering 
firms,  the  solution  has  to  be  tailored  to  the  capabilities  of  the  firm.  Unlimited  fund¬ 
ing  can  accelerate  schedules,  but  technological  barriers  that  even  additional  funding 
cannot  overcome  still  exist. 
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Next,  design  goals  were  established  and  evaluated  using  TRL  definitions.  Also,  a  risk 
management  plan  was  generated  to  help  determine  the  order  of  technological  progression. 
High-risk,  critical  systems  were  developed  first,  followed  by  the  integration  of  less  essen¬ 
tial  sub-systems.  The  progressive  introduction  of  technology  was  accomplished  through 
iterative  prototyping.  This  construction  method  allowed  for  rapid  design  changes  not  only 
to  address  current  issues  but  also  mitigate  future  risk  concerns. 

•  Risk  was  among  the  most  difficult  aspects  of  development  to  identify  and  manage. 
The  did  not  in  any  way  anticipate  the  amount  of  effort  that  would  be  required  while 
working  on  the  UAV  interface.  It  was  identified  as  a  top-level  risk,  but  the  difficulty 
of  the  process  was  inadequately  assessed.  The  result,  restated  in  the  following  bullet, 
was  unwarranted  confidence  in  a  critical  sub-system  that  later  rendered  the  entire 
system  unusable. 

•  Assigning  a  Technical  Readiness  Level  (TRL)  to  the  system  was  also  highly  subjec¬ 
tive.  This  goes  hand-in-hand  with  risk  and  development  prioritization.  For  example, 
at  the  completion  of  POC-4  (see  Section  5.6),  the  team  determined  that  the  UAV  in¬ 
terface  was  at  a  higher  readiness  level  than  was  actually  the  case.  This  resulted  in 
last-minute  design  changes  just  to  complete  the  final  phase  of  testing. 

Throughout  the  prototyping  process,  the  suitability  of  the  system  was  continuously  as¬ 
sessed.  This  was  accomplished  through  the  use  of  developmental  test  and  evaluation 
(DT&E).  The  purpose  of  the  tests  was  to  evaluate  the  current  TRL,  and  determine  the 
status  of  perceived  risks  as  they  evolved.  Also,  the  tests  were  used  to  verify  that  the  de¬ 
sign  solution  was  meeting  system  requirements.  These  findings  were  critical  to  making 
informed  decisions  about  the  direction  of  the  desired  prototype  evolution  as  the  research 
moved  forward. 

•  Focusing  again  on  the  UAV  interface,  the  importance  of  testing  in  relevant  environ¬ 
ments  became  apparent  and  circles  back  to  assigning  the  correct  TRL.  POC-4  was 
assigned  at  TRL-5,  which  requires  a  relevant  environment.  However,  the  UAV  used 
for  this  test  was  not  representative  of  an  operational  UAV.  This  easily  missed,  minor 
difference  between  the  two  aircraft  rendered  the  system  unusable  on  the  first  day  of 
final  testing. 

•  Given  schedule  constraints,  simultaneous  development  of  sub-systems  was  required. 
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This  is  not  an  unusual  practice  for  engineering  projects.  However,  the  efficiency 
gained  from  this  method  can  be  entirely  lost  if  communication  breaks  down  between 
development  teams.  It  has  been  mentioned  that  the  team  for  this  development  was 
only  two  individuals,  representing  mechanical  and  electrical  leads.  However,  com¬ 
munication  was  still  essential  among  the  team  members.  Many  design  decisions 
made  from  a  mechanical  perspective  had  an  impact  on  the  electrical  side,  and  vice- 
versa. 

At  the  completion  of  prototype  construction,  the  final  stage  of  developmental  tests  and 
evaluations  were  conducted  at  the  ARSENL  testing  facility.  The  Automated  Multi-Plane 
Propulsion  System  (AMPPS)  solution  either  met,  or  was  predicted  to  meet,  all  requirements 
established  at  the  beginning  of  the  design  process.  It  was  established  at  a  TRL  of  6,  and 
technological  risks  had  been  minimized.  The  solution  was  delivered  on  time  and  under 
budget.  The  success  of  the  system  was  directly  attributed  to  the  team’s  adherence  to  using 
established  SE  practices  from  research  conception  to  completion.  Concluding  findings 
were: 

•  As  mentioned,  the  prototype  was  delivered  on-time.  However,  it  was  expensive  to 
correct  design  issues  that  arose  late  in  the  development  process.  Several  compo¬ 
nents  had  to  be  shipped  overnight  to  remain  on  schedule.  The  ordering  process  was 
such  that  packages  would  arrive  anywhere  between  one  week  and  one  month  later. 
Shipping  delays  -  or  supply-chain  logistics  for  large-scale  operations  -  can  have  a 
negative  impact  on  every  aspect  of  development.  In  addition  to  schedule  slips,  there 
were  times  when  testing  could  not  be  performed  while  the  team  was  waiting  for 
delivery  of  a  component.  However,  the  design  effort  had  to  continue;  therefore,  de¬ 
cisions  were  made  based  on  incomplete  testing  results.  One  example  of  this  was  the 
requirement  to  order  a  speed  controller  before  the  shunt  arrived  to  measure  amp-flow 
in  the  system.  The  team  spent  approximately  $600  on  a  controller  that  did  not  work. 
Fortunately,  funding  was  available  to  help  mitigate  these  issues,  but  that  is  not  always 
the  case  (nor  is  it  a  best-practice  approach). 

•  During  design  and  construction,  it  was  easy  to  underestimate  the  time  required  to 
perform  the  “simple”  tasks.  It  was  later  discovered  that  nothing  is  simple  until  it  is 
complete.  Focusing  on  the  perceived  major  tasks  and  leaving  trivial  items  for  last  is 
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likely  to  result  in  an  unfinished  solution. 

•  As  observed  during  the  RULE  launcher  development,  the  AMPPS  prototype  was  ca¬ 
pable  of  cycle  times  that  far  exceeded  the  UAV  staging  procedure  used  by  ARSENL. 
Mechanical  limitations  of  the  launcher  were  no  longer  the  choke  point  in  the  opera¬ 
tional  flow.  Further  automation  of  the  staging  process  will  be  required  to  fully  utilize 
AMMPS’s  cycle-time  performance. 

•  The  launcher  was  mostly  operated  by  the  development  team  during  testing.  Occa¬ 
sionally,  a  member  from  ARSENL  would  load  the  UAV  or  command  a  launch  from 
the  wireless  controller.  It  was  interesting  to  note  that,  what  seemed  intuitive  to  the 
design  team  was  not  necessarily  intuitive  to  the  user.  The  importance  of  end-user 
feedback  throughout  the  design  process  was  realized. 


7.2  Recommendations  for  Future  Work 

The  work  outlined  in  this  study  is  only  a  starting  point  for  exploring  launcher  technologies 
related  to  swarming  UAVs.  This  field  of  study  is  in  its  infancy,  and  would  greatly  benefit 
from  future  research.  Beyond  the  mechanical  design  of  launching  systems,  there  are  multi¬ 
ple  contributing  factors  that  affect  launching  performance.  Some  of  the  high-level  aspects 
to  consider  are: 

System  of  Systems  Integration  It  is  highly  probable  that  these  launching  systems  will 
eventually  be  deployed  aboard  ships,  surface  vehicles,  and  perhaps  other  aircraft. 
The  integration  of  these  systems  into  highly  complex,  mobile  platforms  presents  an 
entirely  new  set  of  challenges  to  overcome.  Studies  should  be  performed  that  explore 
the  changes  in  manning  requirements,  Concept  of  Operations  (CONOPS),  effects  on 
war  fighting  capabilities,  supportability,  and  survivability,  to  name  a  few. 

Human  Factor  Considerations  Conceivably,  the  continued  development  of  advanced  au¬ 
tonomy  will  one  day  permit  a  single  technician  to  control  hundreds,  or  even  thou¬ 
sands,  of  UAVs.  If  this  capability  is  realized,  the  launching  systems  used  to  deploy 
these  units  will  require  the  same  level  of  autonomy.  This  also  applies  to  the  recovery 
of  swarms. 

CONOPS  The  necessity  to  study  ground-crew  operations  is  closely  linked  to  the  re¬ 
quired  automation  of  launch  and  recovery  systems.  As  was  seen  in  the  CONOPS 
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of  ARSENL,  the  material  solution  was  no  longer  a  limiting  factor.  If  taking  full  ad¬ 
vantage  of  the  afforded  cycle  rate  using  the  AMPPS  solution  is  desired,  further  study 
will  be  required  to  evaluate  crew  processes  and  optimize  efficiency. 

Specifically  for  the  AMPPS  prototype,  there  are  several  areas  of  work  that  deserve  contin¬ 
ued  study.  Primarily,  the  system  would  benefit  from  continued  prototype  development  and 

testing  in  an  operational  environment.  The  areas  of  focus  should  be: 

Weight  Reduction  The  materials  chosen  for  construction  were  readily  available  and  easy 
to  construct.  Once  the  system  matures  beyond  the  prototype  stage,  there  would  be 
great  value  in  exploring  advanced  manufacturing  techniques  to  reduce  weight.  For 
example,  changing  the  framing  material  from  aluminum  to  a  composite  structure  like 
carbon  fiber  would  reduce  the  weight  by  more  than  100  pounds.  This  was  briefly  con¬ 
sidered  as  an  option  during  prototype  development,  and  would  cost  approximately 
$1500  to  implement. 

Multiple  Platform  Compatibility  Currently,  the  UAV  interface  design  is  only  capable  of 
launching  a  Zephyr  II  UAV.  However,  modifying  the  interface  to  contact  points  that 
are  common  to  most  aircraft  (for  example,  the  trailing  edge  of  a  wing)  would  greatly 
contribute  to  the  versatility  of  the  system. 

Supporting  Systems  The  system  demonstrated  a  launch  cycle  time  of  12  seconds.  Eight 
seconds  were  devoted  to  the  human  element  of  loading  the  UAV  for  launch.  Perfor¬ 
mance  could  be  further  enhanced  through  the  development  of  an  automated  loading 
system  for  the  UAVs.  Conceivably,  this  could  be  realized  through  the  addition  of  a 
hopper-type  attachment.  Such  a  device  would  reduce  cycle  times  and  relieve  techni¬ 
cian  workload. 

Continued  Testing  Time  constraints  limited  the  amount  of  testing  that  could  be  per¬ 
formed.  Little  is  known  about  the  long-term  survivability  of  the  system.  Contin¬ 
ued  testing  should  be  targeted  to  determine  the  reliability,  probable  modes  of  failure, 
maintainability,  and  performance  degradation  over  time. 
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APPENDIX: 

AMPPS  Bil 

1  of  Materials 

Table  1:  AMPPS  Mechanical  Bill  of  Materials 

Item 

Vendor 

Part  Number 

Unit  Cost 

Quantity 

Total  Cost 

1/2"  Shaft  Base  Mount 

McMaster 

185K3 

$17.40 

2 

$34.80 

1/2"  Steel  Drive  Shaft 

McMaster 

1346K19 

$23.53 

1 

$23.53 

Collar  Clamp 

McMaster 

6435K14 

$2.11 

4 

$8.44 

1/4"  Key  Stock 

McMaster 

98535A450 

$11.10 

2 

$22.20 

ANSI  40  Idler  Sprockets 

McMaster 

6663K41 

$28.78 

2 

$57.56 

ANSI  40  Roller  Chain 

McMaster 

6261K173 

$90.80 

1 

$90.80 

Connecting  link  for  ANSI  No.  35  Roller  Chain 

McMaster 

6261K191 

$0.82 

2 

$1.64 

Connecting  link  for  ANSI  No.  40  Roller  Chain 

McMaster 

6261K193 

$0.87 

2 

$1.74 

Horizontal  tab  attachment  link  for  ANSI  40 

McMaster 

732 1K7 

$2.94 

3 

$8.82 

Shoulder  Screw  for  Japanese  Bearings 

McMaster 

91259A709 

$1.97 

8 

$15.76 

Mount  Tabs  for  Wheel  Motors 

McMaster 

47065T155 

$1.79 

8 

$14.32 

Wheel  motor  mount  bolts 

McMaster 

47065T234 

$1.58 

4 

$6.32 

Extra  Concealed  Fasteners 

McMaster 

47065T156 

1.91 

12 

$22.92 

Switch  Panel 

McMaster 

8560K239 

8.63 

1 

$8.63 

Extra  Anchor  Fasteners 

McMaster 

47065T154 

3.89 

10 

$38.90 

Sheet  for  linear  guide 

McMaster 

8589K64 

$42.50 

1 

$42.50 

Linear  Guide 

McMaster 

93095K5 

$30.96 

3 

$92.88 

Shelving  Supports 

McMaster 

47065T224 

$4.06 

24 

$97.44 

Screws  to  mount  Shelves 

McMaster 

90909 A532 

$11.69 

3 

$35.07 

Nuts  for  shelf  screws 

McMaster 

92673 A1 19 

$5.86 

1 

$5.86 

Spare  Nuts 

McMaster 

92673 A1 13 

$3.79 

1 

$3.79 

U-Bolt  Guard 

McMaster 

3043T4 

$6.97 

1 

$6.97 

Primary  Sprocket 

McMaster 

2500T48 

$22.34 

1 

$22.34 

80/20  Frame 

GA  Worth  Company 

$1,187.59 

1 

$1,187.59 

7"  Main  Drive  Sprockets 

McMaster 

6236K14 

$60.50 

2 

$121.00 

Pneumatic  Caster  Wheel 

Uline 

H-3328BL-SWB 

$49.00 

2 

$98.00 

Motor  mount  and  pillow  bearing  mounting  screws 

McMaster 

91259A619 

$1.27 

12 

$15.24 

Motor  mount  and  U-Bolt  guard  mounting  hardware 

McMaster 

47065T229 

$1.46 

8 

$11.68 

Main  Sprocket  Drive  Shaft 

McMaster 

8488T83 

$27.10 

2 

$54.20 

Battery  terminal  cover  (black) 

McMaster 

69875K94 

$2.00 

5 

$10.00 

Battery  terminal  cover  (red) 

McMaster 

69875K94 

$2.00 

5 

$10.00 

Roller  chain  guide 

McMaster 

93095K18 

$188.64 

1 

$188.64 

U-Bolt  mount 

McMaster 

6068K23 

$25.99 

2 

$51.98 

Plane  guide  UHMW  tape 

McMaster 

7344A24 

$8.03 

2 

$16.06 

ANSI  40  Roller  Chain 

McMaster 

6261K173 

$45.40 

1 

$45.40 

Fastening  tabs  for  15  Series  Extruded  Aluminum 

McMaster 

47065T229 

$1.46 

60 

$87.60 

End  Caps  for  10  Series  Extruded  Aluminum 

McMaster 

47065T91 

$1.20 

10 

$12.00 

End  Caps  for  15  Series  Extruded  Aluminum 

McMaster 

47065T87 

$1.50 

4 

$6.00 

1"  Pillow  Mount  Bearings 

McMaster 

5057N1 

$82.14 

4 

$328.56 

Wheel  Adaptor  Plate 

Robot  Marketplace 

NPC-PH448 

$20.00 

2 

$40.00 

14"  Flat  Proof  Wheel 

Robot  Marketplace 

NPC-PT5306 

$87.94 

2 

$175.88 

Roller  Chain  Guide  Tape 

McMaster 

76675A23 

$36.53 

1 

$36.53 

Secondary  Sprocket 

McMaster 

2500T62 

$57.24 

1 

$57.24 

Scotch  Extreme  1"  x  3"  Black  Strip 

Home  Depot 

051131642546 

$3.57 

1 

$3.57 

Loctite  242  Blue  Threadlocker 

Home  Depot 

079340242005 

$6.47 

1 

$6.47 

0.22in  thick,  18x24  in  Acrylic  Sheet 

Home  Depot 

769125020316 

$19.97 

1 

$19.97 

0.093in  thick,  1 8x24  in  Acrylic  Sheet 

Home  Depot 

769125010515 

$9.78 

4 

$39.12 

Adjustable  Flag  Bracket 

Home  Depot 

792723402253 

$6.97 

1 

$6.97 

Total  Mechanical  Cost 

$3,292.93 
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Table  2:  AMPPS  Electrical  Bill  of  Materials 


Item 

48V  DC  Main  Drive  Motor 

AmpFlow  Wheel  Motor 

12V,  22Ah  Battery 

ANL  Fuse  Holder 

Manual  ON/OFF  Switch 

8AWG  Connectors  for  Wheel  Motors 

8AWG  Ring  Terminals 

Keeper  8ft  x  lin  Lashing  Strap  (2  pack) 

RoboteQ  HDC2450  Brushed  DC  Motor  Controller,  Dual  Chan¬ 
nel,  150A,  50V,  Encoder  in,  USB,  CAN 
Hook-Up  Wire  -  Assortment  (Solid  Core,  22  AWG) 

XS  Power  580  Short  Battery  Post  Adapters  M6 
Bussmann  ANN  Very  Fast- Acting  Current  Limiters  ANN300 
Roboteq  HDC2460S  Brushed  DC  Motor  Controller,  Single  Chan¬ 
nel,  300A,  60V,  Encoder  in  USB 

Harsh  Environment  High-Amp  Distribution  Bar  -  1  Circuit,  250 
Amps  @  300  VAC,  4  Stud  Terminals 

Clear  Cover  for  9290T17  Harsh  Environment  High- Amp  Distri¬ 
bution  Bar 

Standard  Ring  Terminal  -  Vinyl  Insulated,  22-18  AWG,  3/8" 
Screw/Stud  Size 

Gigavac  GXNC14CB  Normally  Closed  350+  Amp  12-800  Vdc 
Contactor  with  24  Vdc  Coil 

Standard  Heat-Shrink  Ring  Terminal8  AWG  Wire  Size,  3/8" 
Screw/Stud  Size 

Standard  Heat-Shrink  Ring  Terminal22- 1 8  AWG  Wire  Size,  3/8" 
Screw/Stud  Size 

Standard  Ring  TerminalVinyl  Insulated,  8  AWG,  1/2"  Screw/Stud 
Size 

Ultra-Flexible  Wire  8  Gauge,  Black,  10  ft  long 
45  Feet,  18  AWG  stranded  wire  (three  15  ft  rolls) 

SPST  Rocker  Switch 

Noco  4  Channel  Genius  Charger 

T-Slot  Cover,  6’  Long  for  1-1/2"  High  Aluminum  T-Slotted  Fram¬ 
ing  Extrusion 

DROK  10A/50W  9-32V  12V/24V  to  5V  Car  DC  Voltage  Con¬ 
verter  Regulator  Power  Supply,  Waterproof 


Vendor 

Part  Number 

Unit  Cost 

Quantity 

Total  Cost 

ElectricMotorsport 

Motenergy  EMC-R-LS 

$525.00 

1 

$525.00 

AmpFlow 

W43-500-SR- 1  OB 

$498.00 

2 

$996.00 

Amazon 

XP750 

$99.99 

4 

$399.96 

Amazon 

EWFH 

$6.05 

1 

$6.05 

Amazon 

68180 

$35.30 

1 

$35.30 

McMaster 

8026K2 

$3.38 

8 

$27.04 

McMaster 

7113K223 

$9.09 

1 

$9.09 

homedepot.com 

85243 

$7.97 

1 

$7.97 

roboteq.com 

HDC2450 

$645.00 

1 

$645.00 

sparkfun.com 

PRT- 11367  RoHS 

$16.95 

1 

$16.95 

sonicelectronix.com 

XS  Power  580 

$10.99 

4 

$43.96 

summitracing.com 

BSS-ANN300 

$27.97 

1 

$27.97 

roboteq.com 

HDC2460S 

$660.00 

1 

$660.00 

mcmaster.com 

9290T17 

$44.14 

4 

$176.56 

mcmaster.com 

9290T29 

$28.58 

4 

$114.32 

mcmaster.com 

7113K614 

$11.74 

2 

$23.48 

Gigivac 

GXNC14CB 

$156.00 

1 

$156.00 

mcmaster.com 

7036K74 

$11.36 

5 

$56.80 

mcmaster.com 

7036K63 

$7.06 

3 

$21.18 

mcmaster.com 

7113K716 

$6.50 

1 

$6.50 

mcmaster.com 

7479K13 

$35.80 

2 

$71.60 

Radio  Shack 

2781226 

$7.99 

5 

$39.95 

Radio  Shack 

2750690 

$3.49 

3 

$10.47 

Amazon 

B003JSLWWA 

$320.95 

1 

$320.95 

mcmaster.com 

47065T4 

$4.27 

3 

$12.81 

Amazon.com 

_ 

$15.49 

1 

$15.49 

Total  Electrical  Cost  $4,426.40 
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Table  3:  AMPPS  Sensory  Bill  of  Materials 


Item 

Vendor 

Part  Number 

Unit  Cost 

Quantity 

Total  Cost 

3652_0  -  LCD  Screen  2x20  -  LCM2002J 

phidgets.com 

3652_0 

$25.00 

1 

$25.00 

1 204_0  -  PhidgetTextLCD  Adapter 

phidgets.com 

1 204_0 

$65.00 

1 

$65.00 

1019_1  -  PhidgetlnterfaceKit  8/8/8  with  6  Port  USB  Hub 

phidgets.com 

101 9_ 1 

$125.00 

1 

$125.00 

3919_0  -  T5577  RFID  Tag  -  PVC  Disc  15mm 

phidgets.com 

3919_0 

$1.35 

30 

$40.50 

1024_0  -  PhidgetRFID  Read- Write 

phidgets.com 

1024_0 

$60.00 

1 

$60.00 

1 128_0  -  MaxBotix  EZ-1  Sonar  Sensor 

phidgets.com 

1 128_0 

$35.00 

2 

$70.00 

1042_0  -  PhidgetSpatial  3/3/3  Basic 

phidgets.com 

1042_0 

$70.00 

1 

$70.00 

3053_0  -  Dual  SSR  Relay  Board 

phidgets.com 

305 3_0 

$30.00 

3 

$90.00 

3819_0  -  Acrylic  Enclosure  for  the  1204 

phidgets.com 

3819_0 

$8.00 

1 

$8.00 

3825_0  -  Acrylic  Enclosure  for  the  1024 

phidgets.com 

3825_0 

$8.50 

1 

$8.50 

3822_1  -  Acrylic  Enclosure  for  the  3053 

phidgets.com 

3822_1 

$8.00 

3 

$24.00 

385 1_0  -  Plastic  Shell  Enclosure  for  Spatials 

phidgets.com 

385 1_0 

$5.00 

1 

$5.00 

Odroid-XU3 

ameridroid.com 

Odroid-XU3 

$179.95 

1 

$179.95 

DC  Plug  and  Cable  Assembly  5.5mm 

ameridroid.com 

DC  Plug  and  Cable 

$1.45 

1 

$1.45 

AC/DC  24V  Red  Green  Yellow  LED  Lamp  Industrial  Tower  Sig¬ 
nal  Light 

amazon.com 

al 1080800ux0057 

$39.84 

1 

$39.84 

RTC  Battery 

ameridroid.com 

RTC  Battery 

$11.17 

1 

$11.17 

3824_0  -  Acrylic  Enclosure  for  the  1019 

phidgets.com 

3824_0 

$10.00 

1 

$10.00 

SanDisk  Extreme  Plus  32GB  UHS-I/  U3  Micro  SDHC  Memory 
Card  Up  To  80MB/s  With  Adapter 

amazon.com 

SDSDQX-032G-AFFP-A 

$34.48 

1 

$34.48 

Monoprice  15-Feet  USB  2.0  A  Male  to  Mini-B  5pin  Male 
28/24AWG  Cable  with  Ferrite  Core  (Gold  Plated),  White 

Amazon.com 

108636 

$5.94 

1 

$5.94 

Logitech  Gamepad  F7 10  by  Logitech 

amazon.com 

F710 

$38.48 

1 

$38.48 

Total  Sensors/CPU  Cost 

$912.31 
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